CodeDelta

CodeDelta is a command-line source code metrics tool with a browser-based GUI. It compares two snapshots of a source project — an old version and a new version — and measures exactly what changed, how much, and how complex. It is a professional-grade source code analysis tool for macOS, Linux, and Windows.

Core Principle

If your source files are constantly being changed, the source base is not stable and is not ready for release. CodeDelta makes this visible. Every build, every sprint, every release — run CodeDelta and watch the churn numbers. A healthy codebase shows decreasing churn as a release approaches. A codebase that remains "hot and active" near release is a risk.

Key Features

• Churn Analysis — CHG/DEL/ADD/CRN_SLOC and CHG/DEL/ADD/CRN_LLOC per file and project
• AI Audit (GSS) — detects AI-generated code by measuring structural patterns
• Agent Scan (AIS) — detects code that initiates AI agents at runtime
• Full metric set — LOC, SLOC, LLOC, PLOC, COM_LOC, BYTES, NFILE, all churn metrics
• Metric Sets — user-defined named subsets of metric columns for filtered reports
• Excluded Directories — skip vendor, test, or generated code directories
• Snapshot Date — tag each run with the date the source was extracted
• O/X CSV rows — old metrics and diff rows per changed file
• Myers algorithm with Jaccard similarity — more accurate than GNU diff
• Two-pass LLOC — function-boundary-aware logical line counting
• 30+ languages supported
• SQLite database — no server required, accumulates every run for trend analysis
• Browser GUI — runs locally on port 7654

The Difference Between SLOC and LLOC

SLOC (Source Lines of Code) is a physical count — the number of non-empty, non-comment lines in the file. Two statements on one line = 1 SLOC.

LLOC (Logical Lines of Code) is a semicolon count — the number of logical statements, excluding those inside comments or string literals. One statement spread over three lines = 1 LLOC. This is invariant to formatting and is the preferred metric for measuring real code change.

int i=0; float j=0;  // This is 2 LLOC, 1 SLOC

cout << "Testing"
     << " Hello"
     << " there.";   // This is 1 LLOC, 3 SLOC

What Gets Measured

CodeDelta counts all source files recursively under the base directory, maps each file to a language by extension, and counts metrics per file. For comparisons, files are matched by relative path. A file present in the new project but not the old is Added (N). A file in the old but not the new is Deleted (D). A file present in both is either Changed (C) or Unchanged (U).

Supported Languages

CodeDelta supports over 30 languages out of the box. Full two-pass LLOC (Logical Lines of Code) is computed for C/C++, C#, Java, JavaScript/TypeScript, Python, PHP, SQL, Ruby, Perl, and Shell. For Ada, Assembly, CSS, Fortran, IDL, PowerBuilder, PL/SQL, VHDL, VB, XML, and Windows Batch, SLOC and LLOC are equal (no separate logical-line lexer). HTML, ASP, and JSP use the HTML lexer (SLOC only).

See the complete extension-to-language reference in section 03 (GUI Guide → Extension Overrides) for which file extensions auto-detect to which language. Custom mappings can be added without recompiling via the Extension Overrides field.

CodeDelta computes the source code metrics most commonly used in software-engineering analysis: SLOC, LLOC, comment counts, file counts, and per-language breakdowns. See the Metrics Reference table above for the full set.

Size Metrics

Change Metrics (per file and project)

File Churn Metrics (project level only)

File Status Codes

Two-Pass LLOC Algorithm

LLOC is computed in two passes. Pass 1 strips all comments and string literals, then counts semicolons. Pass 2 identifies function boundaries using brace counting and signature detection, allowing CodeDelta to attribute LLOC to specific functions. The two-pass approach resolves the common ambiguity where a single logical statement spans multiple physical lines.

When LLOC diverges significantly from SLOC (ratio > 3.0 or < 0.3), CodeDelta flags the file with an LLOC warning in the report. This usually indicates unusual formatting — very long chained expressions, or highly condensed single-line code.

Start the GUI server from the Terminal:

python3 /Applications/CodeDelta/codedelta_server.py

Then open http://localhost:7654 in your browser. The GUI runs entirely locally — no internet connection required, no data leaves your machine.

Analysis Mode Selector

The Run Analysis tab is split into two columns. Pick whichever fits the work you're doing:

Compare Projects (left column) — requires Old and New directories

Single Project (right column) — requires only one directory

Run Analysis Fields

Metric Sets

A Metric Set is a named subset of metric columns. When active, only the selected metrics appear in the HTML report table and CSV output. This is useful for management reports that only need CHG_LLOC and ADD_LLOC, without the full detail of every metric.

To create a Metric Set:

1. Click Manage Sets next to the Metric Set dropdown.
2. Enter a name for the set (no spaces — underscores are fine).
3. Tick the metric codes you want to include.
4. Click Save Set.

The set is saved in the database and appears in the dropdown for future runs. To edit an existing set, click Edit beside it — it loads into the editor. To delete, click Delete.

To run without a metric set filter, leave the dropdown on — All metrics (no filter) —.

Available metric codes for sets: LOC, SLOC, LLOC, PLOC, COM_LOC, J_COM, C_COM, EOL_COM, Bytes, CHG_SLOC, DEL_SLOC, ADD_SLOC, CRN_SLOC, CHG_LLOC, DEL_LLOC, ADD_LLOC, CRN_LLOC, CHG_COM, DEL_COM, ADD_COM, CRN_COM, CHG_FILE, DEL_FILE, ADD_FILE, CRN_FILE

Excluded Directories

Enter a comma-separated list of directory names to exclude from both the old and new scans. For example: vendor,tests,third_party,generated. The names are matched against each path component — you do not need to provide full paths.

Built-in excluded directories (always skipped): .git, .svn, .hg, node_modules, __pycache__, vendor, dist, build, Debug, Release

Excluded directories are stored in the database run record and shown in the report header, so you always know what was and wasn't included in a historical run.

Extension Overrides

Some organisations use non-standard file extensions — for example .h2 for C++ headers, .inc for PHP include files, or .ksh for shell scripts. By default CodeDelta ignores files with unrecognised extensions. Extension overrides let you map any extension to an existing language parser without recompiling.

Enter a comma-separated list of ext=lang pairs in the Extension Overrides field:

h2=cpp,inc=php,ksh=sh

The target language can be any known extension (cpp, py, java, sh etc.) or a language name. Unknown target languages are silently ignored. The override takes effect before directory scanning, so all file matching uses the updated map.

Complete extension reference

When mapping a custom extension via the override field, the target side of the ext=lang pair can be any of the codes above (e.g. cpp, py, java, sh, f90). Both the alias and the destination must already be known to CodeDelta — unknown destinations are silently ignored.

Results Tiles

After a run, results appear as coloured tiles in four groups:

• LLOC Change — CHG_LLOC (amber), DEL_LLOC (red), ADD_LLOC (green), CRN_LLOC (purple)
• SLOC Change — same colour scheme for SLOC metrics
• Project Totals — Total SLOC, Total LLOC, PLOC, COM_LOC (all grey/neutral)
• File Churn — NFILE, CHG_FILE, ADD_FILE, DEL_FILE, CRN_FILE

History Tab

Shows all previous runs stored in the selected database. Columns include run date, snapshot date, project, old/new labels, file counts, SLOC/LLOC totals, and churn metrics. Click any row to open its HTML report.

Trend Tab

Charts CRN_SLOC and CRN_LLOC over time for a selected project. A declining trend indicates the codebase stabilising toward release. An increasing trend near a release deadline is a quality risk.

Basic Usage

codedelta <old-dir> <new-dir> [options]

Full Options

Exit Codes

CSV Output Format

The CSV has one header row and one or more data rows per file. For changed files, three rows are output:

• C row — new file metrics
• O row — old file metrics (what the file looked like before)
• X row — arithmetic diff (new minus old)

The CSV output format is compatible with standard spreadsheet tools. Unchanged and deleted files have one row only. The file ends with a TOTAL row and a NFILE summary row.

If a Metric Set is active via --metric-set, only the specified columns appear in the CSV header and data rows.

Example: Nightly Build Integration

#!/bin/bash
codedelta /builds/project-v1.1 /builds/project-v1.2 \
  --project "MyApp" \
  --old-label "v1.1" \
  --new-label "v1.2" \
  --snapshot-date "$(date +%Y-%m-%d)" \
  --exclude "vendor,node_modules,generated" \
  --db /var/lib/codedelta/myapp.db \
  -o /var/www/reports/myapp-latest.html \
  --csv /var/www/reports/myapp-latest.csv \
  --threshold-churn 5000 \
  -q

if [ $? -eq 2 ]; then
  echo "ALERT: churn exceeds threshold — build is hot"
  exit 1
fi

Example: Metric Set for Management Report

codedelta /src/old /src/new \
  --metric-set "SLOC,LLOC,CHG_LLOC,ADD_LLOC,CRN_LLOC,CHG_FILE,CRN_FILE" \
  -o management_report.html \
  --csv management_report.csv

CodeDelta detects AI-generated code via two complementary scans:

• AI Code Scan — analyses source files for patterns associated with AI-generated code (the GSS + MLS combination producing an AIC score). Asks the question: "was this code written by an AI?"
• Agent Scan — covered in section 06. Looks for code that initiates AI agents at runtime (SDK imports, dynamic exec patterns, prompt-injection vulnerabilities). Asks the question: "does this code USE AI at runtime?"

The AI Audit mode in the GUI runs BOTH scans in a single pass, producing two separate HTML reports (codedelta_ai_code_scan.html and codedelta_agent_scan.html).

How GSS Works

Each file receives a Generation Signature Score (GSS) from 0 to 100. The score is the weighted sum of several signals. A high score indicates the file exhibits many of the structural patterns associated with AI-generated code. A low score does not prove the code is human-written — it means no unusual patterns were detected.

Risk Ratings

Sensitivity Setting

The sensitivity slider in the GUI controls the threshold for HIGH classification:

• Strict (30) — flags more files, more false positives. Use for high-assurance audits.
• Balanced (50) — recommended for general use.
• Conservative (70) — only flags files with very strong signals.

Validation Results

GSS was validated against two corpora. A set of 26 human-written C++ files produced a mean score of 0.0 with no HIGH ratings. A set of 12 AI-generated files across multiple languages produced a mean score of 48.9 with 2 HIGH and 3 ELEVATED ratings. Zero false positives were observed on the human corpus.

Important Caveats

GSS measures patterns, not intent. A highly disciplined human developer who writes uniform docblocks and systematic null checks will score higher than average. The score is a signal for review, not a determination of authorship. It is most useful when scores are unexpectedly high for files in a codebase where the baseline is known.

ML Score (MLS) and AI Confidence (AIC)

When the ML plug-in is installed, the AI Code Scan report shows two additional columns alongside GSS:

• MLS — Machine Learning Score (0–100). A per-language Random Forest classifier trained on human + AI code samples. Returns the probability the file matches AI-generated code patterns.
• AIC — AI Confidence Score (0–100). Weighted blend of MLS (60%) and GSS (40%). This is the score used for final risk classification when ML is available.

Language coverage

When MLS is unavailable for a language, the AIC column shows — and risk classification uses GSS alone. All other functionality is unaffected.

Risk Bands

Files are placed into risk bands based on the AIC score (or GSS where MLS is not available):

AI Detection Config

The AI Detection Settings card on the Run Analysis page (visible in any AI Audit or AI Code Scan mode) opens a configuration dialog where you can fine-tune detection per language. The card's status line shows "X/Y signals active · N custom patterns" — a quick view of how much of the default scoring is in effect.

Language tabs

The dialog has six tabs: C/C++, Java, Python, C#, JavaScript, Go. The tab bar is sticky — it stays visible as you scroll through long signal lists.

Built-in signal toggles

Each language has a set of built-in signals. You can toggle individual signals on or off. This matters because some signals are context-dependent:

• File header comment — files without an author/copyright header score higher. Toggle this off (recommended, indicated by an amber pill in the dialog) if your coding standards mandate headers on all files. With headers mandated, AI tools instructed to follow your standards will produce them, making this signal unreliable.
• Low macro usage (C/C++) — disable if your codebase has few macros by design.
• Excessive std:: prefix (C/C++) — disable if your style guide requires it.
• Missing Javadoc (Java) — disable if your team uses Javadoc on all methods.
• Uniform operator spacing (Python) — disable if your team enforces spacing via a linter.
• Pascal case ratio (C#) — disable if your style guide enforces strict PascalCase naming.

Signal configuration is saved to ml_config.json in the CodeDelta directory and takes effect on the next analysis run.

Custom patterns

Add patterns specific to your codebase. Four pattern types:

• Keyword / phrase — flags files containing the text. Example: # AI-generated.
• Regex — flags files where the pattern matches. Example: (?i)auto.?generated.
• File path / directory — flags files whose path contains the pattern. Example: /generated/ or _ai.py.
• Structural — records that a structural pattern is expected. Noted in signals for review.

Each custom pattern can be set to Override — when the pattern fires, the file is always rated HIGH regardless of the ML score. Use this for definitive markers in your codebase.

Custom patterns apply across all AI Code Scan and AI Audit runs until removed. Saved to ml_config.json.

The Agent Scan analyses source files for code that initiates AI agents at runtime — code that imports AI SDKs, orchestrates agents, executes dynamic code, or constructs prompts from user input. This is entirely distinct from the AI Audit: Agent Scan detects code that runs AI agents, not code that was written by AI.

How It Works

Agent Scan reads each source file and looks for four categories of pattern using regular expression matching. Each pattern category carries a weight. Files whose total weight exceeds the configured threshold are flagged.

The scan is entirely static — it reads source text only and never executes any code. It works on files even when dependencies are not installed.

AIS Signal Categories

The Rogue Agent Pattern

The most serious finding is the Rogue Agent pattern: a dynamic code execution call (eval, exec, or subprocess) that appears within 10 lines of an AI API call. This pattern indicates code where an AI model's output may directly influence what gets executed on the host machine — a significant and specific security risk.

A file flagged for the Rogue Agent pattern has its AIS rating escalated to HIGH regardless of its total score.

Example of Rogue Agent pattern:

response = client.chat.completions.create(...)   # AI API call
code_to_run = response.choices[0].message.content
exec(code_to_run)                                 # within 10 lines — ROGUE AGENT

CRITICAL Risk Rating

A file that scores HIGH on both GSS (appears AI-generated) and AIS (initiates AI agents) receives a CRITICAL rating. This is the highest-risk scenario: code that nobody may have fully reviewed or understood, which autonomously initiates AI agents at runtime.

Source Viewer

The Agent Scan report includes an inline source viewer. Click View Source on any flagged file to see it with dangerous lines highlighted:

• Red — Rogue agent pattern (eval/exec within 10 lines of AI API call)
• Orange — Agent orchestration pattern
• Amber — AI SDK import
• Blue — Prompt injection vector

SDK Inventory

When AI SDK imports are found, the Agent Scan report includes an SDK Inventory — a list of each recognised AI framework detected and the number of files importing it. This gives a quick overview of which AI dependencies are present across the codebase.

Honest Limitations

False Positives

Agent Scan will produce false positives in some situations:

• Test files that import AI SDKs to mock them will be flagged even though they don't invoke real agents. Use the Exclude Directories field to skip tests and test directories.
• Configuration and example files that reference SDK names in comments or strings may occasionally trigger import detection.
• Documentation generators that import SDKs to build API docs will be flagged.

The source viewer is the most effective tool for investigating potential false positives — it shows exactly which lines triggered each flag.

Languages Supported

Agent Scan analyses all source files regardless of language but SDK import detection patterns are primarily calibrated for Python, JavaScript, and TypeScript — where AI agent frameworks are most commonly used. C++, Java, and C# projects that call AI APIs via HTTP without a recognised SDK will have lower AIS scores but may still be flagged for dynamic execution patterns.

CodeDelta integrates with any CI/CD system or version control system that can export source files to a local directory. It does not interface directly with any CMVC system — it requires plain directory copies of your source.

Churn Threshold Gate

Use --threshold-churn <n> to fail the build if CRN_LLOC exceeds a threshold. Exit code 2 means the threshold was exceeded.

Jenkins Example

stage('Code Metrics') {
  steps {
    sh """
      codedelta ${WORKSPACE}/old ${WORKSPACE}/new \
        --project "${JOB_NAME}" \
        --old-label "${OLD_TAG}" \
        --new-label "${NEW_TAG}" \
        --snapshot-date "${BUILD_DATE}" \
        --exclude "vendor,tests" \
        -d ${WORKSPACE}/codedelta.db \
        -o ${WORKSPACE}/report.html \
        --threshold-churn 10000 -q
    """
  }
}

GitHub Actions Example

- name: Run CodeDelta
  run: |
    codedelta ./old ./new \
      --project "${{ github.repository }}" \
      --old-label "${{ github.event.before }}" \
      --new-label "${{ github.sha }}" \
      --snapshot-date "$(date +%Y-%m-%d)" \
      --exclude "vendor,node_modules" \
      -o report.html --csv report.csv -q

Database Access

The SQLite database (codedelta.db) accumulates every run. You can query it directly:

sqlite3 codedelta.db "
  SELECT r.run_at, rt.crn_lloc, rt.total_sloc
  FROM run r JOIN run_totals rt ON r.id = rt.run_id
  WHERE r.project_id = (SELECT id FROM project WHERE name = 'MyApp')
  ORDER BY r.run_at DESC LIMIT 10;"

Key DB Tables

The Myers Algorithm

CodeDelta uses the Myers diff algorithm for file comparison, which finds the shortest edit script between two files. This is more accurate than simple line-by-line comparison for files that have been significantly restructured.

Jaccard Similarity

Before running the full Myers diff, CodeDelta uses Jaccard similarity to detect file renames and large-scale moves. A file that appears deleted in the old snapshot and created in the new, but with high token similarity, is treated as a rename rather than a delete+add. This prevents inflated churn numbers from routine refactoring.

LLOC vs GNU diff

LLOC comparison works by tokenising each file's semicolon-terminated statements and running Myers on the resulting token stream rather than the line stream. This means a purely cosmetic reformatting — changing indentation, line breaks, or spacing within a statement — does not register as a change. Only actual logical changes increment CHG_LLOC.

PLOC Definition

PLOC counts lines beginning with # (after optional whitespace) in C/C++ and C# files. This includes all preprocessor directives: #include, #define, #ifdef, #ifndef, #endif, #pragma, #undef, #if, #else, #elif, #error, #warning. PLOC is included within SLOC and LOC — it is not subtracted, it is identified separately for clarity.

Comment Counting

J_COM counts /** ... */ Java-style docblock comments. C_COM counts /* ... */ C-style block comments. EOL_COM counts // to-end-of-line comments. A multi-line block comment counts as one comment regardless of how many lines it spans. COM_LOC = J_COM + C_COM + EOL_COM.

Character Literal Handling

Single-quoted character literals are correctly excluded from LLOC counting. A semicolon inside a character literal — such as char c = ';' — is not counted as a logical statement. This applies to C/C++, C#, Java, and JavaScript. Escape sequences ('\\', '\n', '\0') are also handled correctly. This was a known limitation corrected in v1.4.1.

CodeDelta requires a valid licence to run. Two licence types are available:

Installing a Licence

Set the environment variable before running:

export CODEDELTA_LICENSE="CD-TIMED-20270503-XXXXXXXXXXXXXXXXX"
./codedelta old/ new/

Or store it in a file in your home directory:

echo "CD-TIMED-20270503-XXXXXXXXXXXXXXXXX" > ~/.codedelta_license

Contact

For licensing, volume pricing, or academic licences: admin@stackbun.com

certify.py is a standalone tool that answers the question every AI-assisted development team needs answered: "Is this the correct, tested version of every file?"

It works by recording the SHA256 fingerprint of every source file at the exact moment your tests pass. If any file changes after that — whether by accident, by an AI session, or by copying the wrong version — certify.py tells you immediately.

certify.py requires Python 3.8 or later and has no other dependencies. Drop it anywhere and run it directly. It is not part of the CodeDelta distribution —.

Quick Start

# After your tests pass, certify your files:
python3 certify.py certify --build 1 --src . --tests "pytest"

# Check status at any time:
python3 certify.py safe --src .

Commands

• certify — runs your tests and records SHA256 fingerprints of all files if all tests pass. Refuses to certify if any test fails.
• safe — plain English safe-to-ship report with traffic-light risk rating (SAFE / LOW / MEDIUM / HIGH). Designed for non-technical users.
• status — compact certification status summary. Use at the start of every session.
• verify — detailed file-by-file comparison against the last certification. Returns exit code 1 if any files are uncertified — suitable for CI/CD pipelines.
• history — certification history for a file or the whole project. Shows which build each file was last changed in and whether it was AI-generated.
• ai-session — tag files as AI-generated. Tagged files appear with ⚡ in all reports and trigger HIGH RISK if they change after certification without re-testing.

Supported Test Frameworks

certify.py works with any test framework. Pass the test command with --tests, or use --tests auto to auto-detect:

python3 certify.py certify --build 2 --tests "pytest"
python3 certify.py certify --build 2 --tests "npm test"
python3 certify.py certify --build 2 --tests "go test ./..."
python3 certify.py certify --build 2 --tests "cargo test"

AI Session Tracking

After every AI coding session, tag the files that were produced:

python3 certify.py ai-session \
  --files src/new_feature.py src/config.json \
  --label "Claude session — added payment module"

Tagged files are marked ⚡ in all certification reports. If a tagged file changes after certification without being re-tested, the safe command reports HIGH RISK.

How Certification Carries Forward

Files that have not changed since their last certification automatically carry their certification forward. Only changed files need re-certifying at each build. The history command shows the full audit trail — which build each file was first certified in, and whether it has changed since.

CI/CD Integration

# GitHub Actions — block deployment of uncertified code
- name: Verify file certification
  run: python3 certify.py verify --src . --strict

verify_files.py is included in the CodeDelta distribution. It verifies that every source file matches its embedded FILE-ID — a SHA256 checksum of the file's own content, stored as a comment in the file itself.

Every file in the CodeDelta source distribution contains a line like:

// FILE-ID: 9b32c6f257db9c1cc28d1cb178dce47fa0ed06027468b56434f4993e01b48113

This ID is the SHA256 of the file content excluding that line. If the file has been modified since the ID was set, the computed hash will not match the stored ID.

Usage

# Verify all files in the current directory
python3 verify_files.py verify .

# Add or update FILE-IDs
python3 verify_files.py add .

Output

  ✓ src/report_html.cpp
  ✓ src/diff_engine.cpp
  ✗ MISMATCH: src/codedelta.cpp
      stored:   212d145ba32f7b43f7cf9516143b6c06...
      computed: 7f3a91d8e4c2b1a9f6d3e8c7b4a2d1f5...

Result: 38 OK, 1 FAILED, 2 skipped

A MISMATCH means the file has been modified since the FILE-ID was last set. Either the modification was intentional (update the FILE-ID with verify_files.py add) or the file has been corrupted or substituted.

CodeDelta uses a three-layer versioning system so that every build is uniquely identifiable.

The three layers

The per-file header block

# FILE-ID: <64-char SHA-256 hash>
# ─── Component versioning ─────────────────────────────────
# CODEDELTA_COMPONENT: ai_ml_plugin
# CODEDELTA_BUILD: 5
# CODEDELTA_BUILD_DATE: 2026-05-28
# CODEDELTA_BUILD_TIME: 19:41
# ──────────────────────────────────────────────────────────

Every tagged Python file carries this block. The build number increments by one on every deploy. Date and time are stamped from the system clock. The FILE-ID is a SHA-256 of the file body (excluding the FILE-ID line itself) — it changes whenever the file content changes.

The /version endpoint

The GUI server exposes http://localhost:7654/version as a JSON endpoint. It returns the master version, the C++ binary's version and build, and an array of every Python component file with its current build number, date, time, and short FILE-ID. Bug reports should include this JSON so the developer knows exactly which build of every component is on the user's machine.

The About box (beta only)

In beta builds, the About box has a "Components" section listing every Python file's build details. In release builds, this section is hidden — end users see only the master version, release date, and licence info.

The deploy.sh utility

The deploy.sh script in the source repo handles the mechanical work of installing a patched file into the runtime location. It:

• Finds the source file in ~/Downloads/ (handles the macOS (N) suffix automatically).
• Backs up the existing file to ~/.codedelta-backups/.
• Bumps the per-file build number and stamps the current date and time.
• Regenerates the FILE-ID by re-hashing the new file body.
• Copies the file to its destination. C++ files trigger a full binary rebuild.

Common commands:

deploy.sh <filename>          # full deploy with backup + version bump
deploy.sh --dry-run <file>    # see what would happen, no changes
deploy.sh --revert <file>     # roll back to most recent backup
deploy.sh --list              # show routing table
deploy.sh --help              # help screen

For full details see CDVC.md in the source repo root.

Note: deploy.sh is a Unix shell script for macOS and Linux. Windows users patching files should copy the patched file manually into the CodeDelta installation directory; the auto-versioning runs server-side and is platform-independent.