Application Architecture
Ice Porter performs source conversion during development. PPJ supplies compatibility behavior when the generated application runs. These are separate stages: installing a translator is not the same as deploying the application's runtime dependencies.
Development: From Source to Application
- Inputs: the SAL application and libraries, resources, report definitions, and an inventory of external integrations.
- Conversion: Ice Porter translates the selected source using a recorded set of options. Its log identifies constructs requiring attention.
- Output: a .NET solution containing translated code, generated compatibility plumbing, and the resources and converted reports selected by the workflow.
- Validation: compile with the chosen PPJ references, resolve conversion warnings, and compare behavior with the original application.
The output is application source that developers can maintain. Generated context scopes, forwarding members, and event dispatch still have a behavioral purpose. Understand them before simplifying them; see context and inheritance.
Runtime: Choose the UI Target
| Desktop | Web |
|---|---|
| The application and PPJ desktop runtime execute in a Windows process. | The application and PPJ Web runtime execute on the server. |
| Windows Forms and supported desktop controls implement the UI. | Wisej.NET coordinates the server-side UI with its browser client. |
| Local files, printers, and COM integrations use the desktop machine's environment and identity. | Server-side file, database, and report operations use the server environment and identity; browser access requires explicit web interaction. |
| Multiple running copies normally have separate process state. | One server process can host multiple users, so shared state needs deliberate ownership. |
This diagram shows the ordinary desktop and browser deployment choices; it is not a specification for every Hybrid or custom hosting arrangement. The PPJ product overview describes the desktop and Wisej.NET targets.
Dependencies at the Boundary
PPJ SQL calls use the configured adapter and ADO.NET provider to reach the database. Provider and database behavior remain relevant: SQL dialect, native clients, authentication, parameter handling, and transaction semantics do not disappear during conversion.
Reporting goes through a supported PPJ adapter to its engine and converted definition. The engine may need additional native components, fonts, licenses, and storage. A report file that opens in a designer does not prove the application can supply the correct runtime data.
External integrations deserve their own inventory: COM servers, files, mail, device access, service calls, and printer behavior. Label where each runs and which identity owns it. For Web, a library's presence on the server does not give the browser direct access to a local device.
Use the Diagram in a Design Review
Annotate a copy with exact versions from the compatibility record, process/machine boundaries, credentials, and data ownership. Trace one business operation from the user's action through the database and back. Then trace a report export and a failed save. Every resource created along those paths needs an owner and a defined end of life.