ORPHANWARE This directory lists the platforms and system families Orphanware Recovery works with, grouped by where they run. For each entry, the status describes where the platform stands now, the risk describes what waiting costs, and the recovery path describes how source gets back into maintainable form. If your exact program is not listed, the deciding factor is the binary you still have, not the label on this page.
Home/Directory
Directory of legacy platforms
The platforms and systems we recover source for, with the status of each, the risk of leaving it as is, and the path back to maintainable source.
Visual FoxProClipper and dBaseVisual Basic 6Delphi and Object PascalParadox and ObjectPALPowerBuilderDataFlexLegacy point of saleFanuc CNCSiemens SINUMERIKHeidenhain CNCDOS industrial software
Business applications
Visual FoxPro
Status: Visual FoxPro applications still run invoicing, inventory, membership, and records in offices that never migrated. Microsoft ended mainstream support for Visual FoxPro in 2015, and the developers who wrote these custom systems have largely retired. The applications themselves remain fast and stable on the machines they know.
Risk of doing nothing: The application is usually tied to one aging PC, one printer setup, and data in DBF tables that only the program fully understands. When that PC or a driver changes, there is no vendor to call and no source to fix. Each year the pool of people who can help shrinks.
Recovery path: Recovery reconstructs readable source from the compiled application, documents the DBF tables and reports alongside it, and verifies the rebuild against the running program. Start with the guide to Visual FoxPro and Clipper options, then a recon for a verdict on your binary.
Business applications
Clipper and dBase (xBase)
Status: Clipper and dBase applications are DOS-era and early Windows xBase programs that still handle billing, inventory, and records in small operations. The tooling is decades old, vendor support ended long ago, and working setups often survive inside DOSBox or a virtual machine.
Risk of doing nothing: These programs depend on precise file locking, index files, and printer behavior that modern systems handle differently. A hardware change can break a workflow that has run untouched for years, and without source there is no way to adjust the program to its new home.
Recovery path: The compiled EXE still holds the procedure logic, and the DBF, index, and memo files define the data. Recovery rebuilds both sides into maintainable source and checks behavior against the original. See the Visual FoxPro and Clipper guide for how the options compare.
Business applications
Visual Basic 6
Status: Visual Basic 6 produced a large share of the custom line-of-business software still running in warehouses, clinics, offices, and shops. The development environment is long out of support, but the compiled applications keep running, often on machines kept old specifically so they continue to work.
Risk of doing nothing: VB6 applications lean on old components, OCX controls, and database drivers that newer Windows versions do not provide. When a component cannot be installed or a driver disappears, the application fails in ways nobody on site can repair, because the source and the original developer are both gone.
Recovery path: Recovery works from the compiled EXE and its supporting files, reconstructing forms logic, procedures, and data access into readable source. The rebuild is compared against the original on the workflows the business actually uses, so changes and migration planning can start from verified behavior.
Business applications
Delphi and Object Pascal
Status: Delphi and Object Pascal applications are common in utilities, industrial tools, and internal business software, valued for fast native binaries that run for years without attention. Many are still in daily use with no surviving source and no contact with the original developer.
Risk of doing nothing: A native binary with no source cannot be patched, ported, or audited. When the operating system, a database connection, or a hardware interface changes, the owner has no path to adapt a program the operation still depends on every day.
Recovery path: Recovery feasibility for Object Pascal was proven on a Free Pascal target on October 19, 2026, recovered and verified across 4,654 fuzz cases. Embarcadero Delphi and VCL forms work is less certain and starts with a recon verdict on your specific binary before any recovery is promised.
Business applications
Borland Paradox and ObjectPAL
Status: Paradox databases and ObjectPAL applications still hold business records in offices that adopted them early and never left. The platform passed through several owners, support faded, and the applications remain tied to the BDE-era tooling they were built with.
Risk of doing nothing: Paradox tables and forms encode years of records and the rules for working with them. As the machines and network setups they rely on age, table corruption, locking problems, and simple hardware loss become harder to recover from without source or documentation.
Recovery path: Recovery documents the table structures and reconstructs the ObjectPAL logic from the delivered application files, so the records and the behavior that manages them can be maintained or migrated deliberately. A recon establishes what application files survive and what can be rebuilt from them.
Business applications
Sybase PowerBuilder
Status: PowerBuilder applications were built heavily for enterprise and institutional back offices, and many still run reporting, records, and transaction workflows. The platform changed owners over the years, licenses and skills grew scarce, and custom applications often outlived the teams that maintained them.
Risk of doing nothing: These applications are usually bound to specific runtime libraries, database drivers, and Windows versions. When the environment shifts, a business-critical workflow can fail with no in-house expertise left to diagnose it and no source available to change it.
Recovery path: Recovery starts from the compiled application and its libraries, reconstructing the DataWindow and script logic into documented, maintainable form where the binary allows. The recon verdict matters here: it separates what can be rebuilt cleanly from what should be documented and migrated instead.
Business applications
DataFlex (character-mode era)
Status: Character-mode DataFlex applications still run order entry, inventory, and service workflows in businesses that value speed at a keyboard. The systems are stable and deeply customized, and they often run in terminal windows that hide how much business logic sits behind them.
Risk of doing nothing: The knowledge of how these applications are set up lives with one or two people, and the compiled programs cannot be adjusted as prices, taxes, forms, or workflows change. A failed server or a lost runtime license can stop order entry entirely.
Recovery path: Recovery reconstructs the application logic from the compiled programs and documents the embedded database structure alongside it. With source back, the business can maintain the character-mode workflows it depends on or migrate them in stages, using the recovered behavior as the specification.
Retail and hospitality
Legacy point of sale platforms
Status: Shops and restaurants still run register and back-office software from point of sale vendors that shut down or discontinued the product. The registers work, the end-of-day reports work, and the business runs on them, but the company behind the software is no longer there.
Risk of doing nothing: POS software touches payments, tax reporting, inventory, and staff workflows at once. When a register PC fails or a reporting requirement changes, the owner cannot call the vendor, cannot get an update, and cannot change the program. The fallback is a rushed replacement during trading hours.
Recovery path: Recovery targets the register and back-office programs the business owns, rebuilding source so reports, pricing rules, and data handling can be maintained or carried into a planned replacement. A recon starts from the programs on one register or back-office machine.
Machine shop
Fanuc CNC controls (0, 6, 10 and 11 era)
Status: Machines with Fanuc controls from these generations are decades old and vendor support and parts grow scarcer, but the iron is usually sound. What strands them is the PC-side software around the control: the transfer and utility programs the shop uses every day.
Risk of doing nothing: When the shop PC fails, a dongle is lost, or a DNC program stops running on a newer computer, a working machine cannot be fed part programs and earns nothing. Replacement conversations start at the price of a machine, for what began as a software failure.
Recovery path: Recovery covers the PC-side programs: DNC transfer, editors, translators, and utilities tied to these controls, verified against the original on real part programs. Proprietary controller firmware is not part of this work. See the legacy CNC controller software guide.
Machine shop
Siemens SINUMERIK controls (810, 820, 850 era)
Status: SINUMERIK controls from these generations still run in shops where the machines remain accurate and paid for. Support centers on newer generations, and the PC-side programs that move files, convert formats, and configure work around these controls are often DOS or early Windows utilities.
Risk of doing nothing: A failed utility or a dead shop PC cuts the control off from the programs and data it needs. The shop is left choosing between hunting for obsolete software copies of uncertain origin and sidelining a machine that still cuts accurate parts.
Recovery path: Recovery rebuilds the PC-side transfer, conversion, and utility programs from the binaries the shop has, and verifies them on the shop's own part programs. Controller firmware stays with the control vendor. The CNC software guide explains the process and its limits.
Machine shop
Heidenhain CNC controls (TNC 145 and 355 era)
Status: Heidenhain TNC controls from these generations are known for staying in service for decades in toolrooms and small shops. The controls keep working, while the PC-side software used to transfer, edit, and back up programs ages on a single shop computer.
Risk of doing nothing: When that computer or its transfer utility fails, programs written at the control or in CAM have no reliable route to the machine. Manual workarounds cost operator time on every job, and a single lost utility can idle a machine the shop depends on weekly.
Recovery path: Recovery targets the PC-side programs around the control: transfer utilities, editors, and format converters, rebuilt to source and compared against the original using real shop files. It does not cover firmware inside the control. Start with the legacy CNC guide and a recon.
Industrial
DOS and early Windows industrial software
Status: Machine vendors shipped DOS and early Windows utilities for testing, configuration, calibration, and data collection, and many of those vendors are gone. The equipment still runs in plants and labs, driven by small programs on old PCs that nobody dares to update.
Risk of doing nothing: These utilities are often the only way to configure or read the equipment they shipped with. When the PC fails or the program stops running, the equipment loses its interface, and the owner is left with hardware that works and no supported way to operate it.
Recovery path: Recovery rebuilds the utility programs from the surviving binaries, documents their settings, file formats, and device communication, and verifies the rebuild against the original on the real equipment workflow. A recon identifies which utility the equipment actually depends on.
Not sure your platform qualifies?
An honest verdict on whether your program can be recovered, what it does, and what a full recovery would take. Fixed price, delivery in about 3 days.