ReAction Developer Studio (ReADevS)

IDE for AmigaOS Classic v3.2.3 and later

ReAction Developer Studio is an IDE for developing software natively on AmigaOS. It makes it easy for you as a developer to write code, then build, execute and debug your resulting program. And everything is at your fingertips in one unified user interface.

ReAction Developer Studio is based on and inspired by Camilla Boemann's great IDE CodeCraft.

From there, the project evolves in its own direction: IDE first, editor second. The editor is a component, not the core identity of the application.

Many thanks and a million kudos to Camilla!

Features

• Shows your project tree as a hierarchical list of source files
• Provides easy modern text editing
• Builds the project tree invoking your build system
• Runs your resulting program
• Does source level debugging with breakpoints and inspection of variables

Minimum Requirements

Amiga (68000 or better), AmigaOS 3.2.3, 1MB free HD, and 1MB free FastRAM.

Additionally you'll need a build system (shellscript, makefile or similar) and a compiler. These toolchains come with their own list of requirements.

Recommended

As fast as possible, as much RAM as possible

---

The software is free and released under GPL2. But it works as an extension to TextEdit so AmigaOS 3.2.3 or better is required.

---

Project Direction

The project is being reorganized and evolved as a native AmigaOS application with explicit subsystem boundaries, clear repository ownership, and a maintainable forward path.

The fork follows an AmigaOS 3.2.3-first policy.

Technical baseline:

• runtime target: AmigaOS 3.2.3
• SDK/API baseline: NDK 3.2R4
• language baseline: C89
• preferred compiler path: vbcc

Key principles:

• native AmigaOS system integration
• explicit ownership and cleanup
• subsystem-oriented source layout
• maintainability over compatibility sprawl
• historical preservation without architectural stagnation

The guiding question is:

What would AmigaOS do?

---

Repository Layout

The repository is organized by responsibility.

Active source tree

• src/ — production source code, grouped by subsystem
• include/ — shared project headers
• catalogs/ — localization source and generated catalog-related output
• build/ — build-system files and compiler-specific build logic
• tools/ — helper scripts
• packaging/ — release, disk, and install assets
• tests/ — smoke, subsystem, and manual test material
• docs/ — architecture, development rules, workflow, and notes

Preserved original baseline

• vendor/codecraft/ — preserved imported original archive

vendor/ is kept as a technical and historical reference. Active development happens outside vendor/.

---

Source Layout

The active source tree is organized by subsystem.

• src/app/ — application lifecycle and top-level coordination
• src/project/ — project model and project workflow logic
• src/debugger/ — debugger mechanics, breakpoints, trap handling, stack analysis
• src/inspectors/ — browser-style debugger views
• src/integration/ — Workbench/editor/plugin/external integration boundaries
• src/common/ — small genuinely shared support code

This layout exists to make ownership explicit and reviewable.

---

Build Direction

The forward-looking build direction of the fork is:

• build/vbcc/ — primary path

Historical or transitional material may also exist:

• build/sas-c/ — secondary or historical path

The project may preserve historical build knowledge, but historical build paths must not define the active architecture.

---

Documentation Map

Start here

• docs/overview/architecture.md
• docs/overview/module-map.md
• docs/overview/build-matrix.md

Development rules

• docs/developer/repo-rules.md
• docs/developer/coding-style.md
• docs/developer/contributing.md
• docs/developer/build-workflow.md
• docs/developer/module-template.md
• docs/developer/review-checklist.md
• docs/developer/testing.md

Migration context

• docs/notes/migration-notes.md

These documents define how the fork is structured, how it should evolve, and how changes are reviewed.

---

Working with the Fork

For contributors

Before making changes:

1. read the architecture and module map
2. follow the repository and coding rules
3. treat build/vbcc/ as the primary path
4. use vendor/ as reference, not as the active development tree
5. document migration decisions when active behavior diverges from the vendor baseline

For structural work

When moving or reorganizing code:

• keep source ownership explicit
• update build references honestly
• keep packaging separate from runtime code
• avoid mixing structure and behavior changes without reason

For behavior changes

When changing runtime logic:

• preserve subsystem boundaries
• make ownership and cleanup visible
• validate the actual changed behavior
• document build or migration implications where relevant

---

Vendor Policy

The original imported Codecraft archive is preserved under:

• vendor/codecraft/

It serves as:

• historical reference
• migration baseline
• diff source
• behavioral comparison point

Do not treat vendor/ as the active code tree. Do not add new features there. If code is migrated or adapted from vendor/, document that clearly in commit history and, where appropriate, in migration notes.

---

Current State

This repository is in an active cleanup and structuring phase. That means some areas may still be transitional, including:

• build scaffolding
• placeholder documentation
• staged migration of modules out of the historical layout model

Transitional content is acceptable as long as it is:

• structurally honest
• documented clearly
• moving toward the active baseline

---

Design Expectations

Changes accepted into this repository should make the active fork:

• clearer
• safer
• more native to AmigaOS
• easier to review
• easier to build and maintain

Not every historical pattern should be preserved. Not every modernization idea is appropriate. The goal is a disciplined AmigaOS-native codebase, not a generic rewrite.

---

Practical First Steps

A new contributor should usually proceed in this order:

1. read docs/overview/architecture.md
2. read docs/overview/module-map.md
3. read docs/developer/repo-rules.md
4. read docs/developer/coding-style.md
5. check docs/notes/migration-notes.md
6. work in the active tree, not in vendor/
7. validate changes against the primary build direction

---

Final Principle

This fork preserves the original project as reference, but develops the active codebase as a structured, maintainable AmigaOS 3.2.3-first project.

In one sentence:

Keep vendor/ as evidence, keep the active tree as the product, and evolve the fork in a way that another disciplined AmigaOS developer can understand and maintain.