NdsForge separates reading, validation, preservation edits, and structural builds so an application can choose the least destructive workflow that fits its task.
NdsImage.Open and OpenAsync accept a path. Stream overloads retain the caller's stream ownership, while memory overloads are useful for small synthetic images and tests. Keep the returned image alive while opening payload streams backed by its source.
Use NdsReadOptions to lower allocation, table, overlay, or hierarchy limits when processing uploads or other untrusted input.
Parsing answers “can this structure be represented safely?” Validation answers “is the represented image internally consistent under these trust inputs?”
Diagnostics have stable codes and severities suitable for application logic. Messages are explanations for humans and should not be parsed.
Extraction validates every host path and refuses traversal, reserved names, collisions, and reparse-point redirection. Choose an overwrite policy explicitly for repeatable automation.
Use NdsImageEditor when preserving the original layout matters. It can change supported header values, replace allocated files, and repair checksums. Review NdsImageEditor.Plan before saving when an application needs to explain physical changes.
Use NdsImageBuilder for new images or structural changes such as adding and removing NitroFS paths. Builders own copies of supplied byte buffers and produce deterministic output from identical state.
The default profile uses NdsForge's deterministic layout. Select NdsImageBuildProfile.Ndstool1503 only when compatibility with the historical tool's verified layout is an explicit requirement.