Welcome! PortableApps Compiler & Management (PortableApps Compiler or Pac-Man for short), is an enhanced, compatibility-aware launcher framework inspired by the PortableApps.com Launcher (PAL). It is designed to support complex, modern, and legacy Windows applications that PAL intentionally does not target. pac-man's framework is built on top of PAL. It introduces a deterministic, crash-resilient segment system for controlled interaction with Windows subsystems while preserving portability principles.
pac-man does not replace PAL. It augments PAL by adding:
- Structured lifecycle segments
- Crash-recovery guarantees
- Explicit rollback journaling
- Windows 10/11–compliant integration patterns
pac-man is designed to behave like a transactional runtime environment, not an installer. pac-man is not a replacement for PAL. It exists to solve a different class of problems.
pac-man is not ready for production deployment. The project is currently under active, foundational development, with core systems still evolving. While major architectural components are designed and implemented, the following remain incomplete or unstable:
- Segment APIs are still subject to change
- Recovery and rollback paths are being hardened and audited
- Edge cases across Windows versions are still being validated
- Long-term compatibility guarantees have not yet been established
- Internal tooling, documentation, and safety checks are incomplete
As a result:
- Behavior may change between revisions
- Configuration formats are not yet frozen
- Backward compatibility is not guaranteed
- Use in production environments may result in unintended system changes
At this stage, pac-man should be considered suitable only for development, testing, and experimentation by advanced users who understand the risks.
Production use is explicitly discouraged until:
- The segment SDK stabilizes
- Crash-recovery logic is fully verified
- Windows 10/11 behavior is exhaustively tested
- Formal release guarantees are documented
pac-man is considered production-ready when:
- A crash cannot leave the host system modified
- Every segment can fail safely
- Recovery is automatic, deterministic, and tested
- Behavior is documented and enforced
- No hidden system state is introduced
For more information on what's planned for pac-man visit our roadmap
- Conservative system interaction
- Optimized for simple, well-behaved portable applications
- Avoids modifying:
- File associations
- Protocol handlers
- Services
- Firewall rules
- Hosts file
- Prefers portability purity over compatibility
- Compatibility-first design
- Supports complex and legacy applications
- Allows temporary system modification with:
- Explicit scope
- Journaling
- Guaranteed rollback
- Treats crash recovery as mandatory
| Feature | PAL | pac-man |
|---|---|---|
| Crash Recovery | Limited | Journal-based |
| File Associations | Not supported | User-scoped |
| URL Protocols | Not supported | Supported |
| Windows Services | Not supported | Temporary |
| Firewall Rules | Not supported | Reversible |
| Scheduled Tasks | Not supported | Session-bound |
| COM Registration | Minimal | Fully tracked |
| Fonts | Limited | Fully reversible |
| Hosts File | Not supported | Transactional |
| Windows 11 Compliance | Partial | Explicit |
To learn more about the differences between PAL and pac-man visit pac-man vs. PAL
pac-man adheres to the following principles:
- No permanent system mutation
- Every mutation must be reversible
- Recovery must not depend on successful startup
- User scope first, system scope only when required
- Deterministic execution order
- Fail closed, not open
Crash recovery in pac-man is:
- Deterministic, not heuristic
- Journal-driven, not best-effort
- Idempotent, safe to re-run
If pac-man detects that a previous session ended unexpectedly, it recovers first, before any new changes are made.
The journal records only what is necessary to undo a change.
It is not a log; it is a rollback ledger.
- Location:
HKCU\Software\pac-man\Journal - One subkey per segment
- No shared keys between segments
- Journal before mutation
- Never infer state
- Never delete data you did not create
- Cleanup must clear the journal
Each segment must fully comply with a strict criteria.
A compliant segment must:
- Be self-contained
- Never assume admin rights
- Never assume it completes
- Never assume a successful cleanup
- Never leak filesystem state
- Have every mutation reversible without context
- Declare changes before mutation
- Be callable from:
- normal lifecycle
- crash recovery
- secondary instance (safe no-op)
pac-man defines the following first-class segments:
- PATH manipulation
- Portable VC++ / .NET handling
- Process-scoped environment setup
- COM registration/unregistration
- DLL lifecycle tracking
- User-scoped font registration
- Temporary font availability
- Junctions
- Hard links
- Symbolic links
- File extensions
- Protocol handlers
- Shell verbs
- Application capabilities (Windows 10/11 compliant)
- Program-specific firewall rules
- Named, reversible entries
- Temporary hostname overrides
- Full snapshot restoration
- On-demand Windows services
- Explicit creation and deletion
- Scheduled tasks
- Explicit naming and teardown
- Runtime
- RegDLL
- Fonts
- Symlinks
- Associations
- Firewall
- Hosts
- Services
- Tasks
Exact reverse order.
This ensures no consumer exists without its provider.
pac-man explicitly avoids:
UserChoicehash tampering- Silent default-app hijacking
- Undocumented Explorer hooks
- Global COM pollution
All shell integration follows documented registry contracts and respects OS safeguards.
- Default execution is non-admin
- Admin-only segments must explicitly check elevation
- No silent privilege escalation
- No persistent background components
This aligns pac-man with least-privilege principles.
pac-man treats failure conservatively:
- Partial apply → full recovery
- Uncertain state → rollback
- Missing journal → do nothing
Data safety is prioritized over feature completeness.
Third-party segments must:
- Follow the lifecycle contract
- Use the journal API
- Register with the dispatcher
- Declare privilege requirements
Segments that violate these rules are considered unsafe.
pac-man is suitable for:
- Portable developer tools
- Security tooling
- Controlled enterprise environments
- Forensic or sandbox workflows
pac-man is not intended for:
- Silent system takeover
- Persistent background services
- Circumventing OS security policies
This README is still being written...