fix(Namdapha): improve button icon loading robustness

[kheersagarpatel]

Summary

Improves the robustness of button icon loading and rendering in NamdaphaButton.cpp by adding defensive file handling, making BMP metadata parsing portable across architectures, and validating rendering inputs before drawing.

Changes

Namdapha - NamdaphaButton.cpp

File loading

• Diff: Added validation for _KeOpenFile() and return early when the icon file cannot be opened.
• Why it worked in Windows: Icon assets were generally available during development, so the failure path was rarely exercised.
• Why it still works: Valid icon files continue to load normally. Missing files now fail gracefully instead of continuing with an invalid file descriptor.
• Why it won't break Windows: This only affects the error path and follows standard file handling practices.

BMP metadata parsing

• Diff: Replaced direct BMPInfo structure access with memcpy() when reading bitmap metadata.
• Why it worked in Windows: x86/x64 architectures generally tolerate unaligned memory accesses performed through structure casts.
• Why it still works: The same bitmap fields are extracted while avoiding architecture-dependent alignment assumptions.
• Why it won't break Windows: memcpy() produces identical values while remaining portable across all supported architectures.

Icon rendering

• Diff: Added validation to ensure both the button information and image data are available before rendering.
• Why it worked in Windows: Valid icon data was typically available, so null rendering paths were rarely encountered.
• Why it still works: Successfully loaded icons render exactly as before. Invalid or missing icon data is now skipped safely.
• Why it won't break Windows: The rendering path for valid icons is unchanged. The additional validation only protects the failure path.

Compatibility

• Existing functionality is unchanged (or breaking changes are explicitly documented).
• MSVC/Windows build toolchain remains fully compatible.
• GCC/Linux build toolchain remains fully compatible.
• No regression in bootloader, kernel, or user-space runtime logic.

Related

Part of #44.

[kheersagarpatel]

Commit: a6c6d6c

Summary

This commit improves the robustness of button icon loading and rendering in XELnch/button.cpp by fixing undefined behavior, making BMP metadata parsing portable across architectures, and strengthening rendering bounds handling.

Changes

XELnch - button.cpp

CreateLaunchButtonIcon

• Diff: Added the missing return icon; statement.
• Why it worked in Windows: MSVC often preserved the return value in the return register, masking the missing return statement.
• Why it still works: The allocated ButtonIcon is now returned explicitly as intended.
• Why it won't break Windows: This removes undefined behavior without changing the function's intended behavior.

BMP metadata parsing

• Diff: Replaced direct BMPInfo structure access with memcpy() when reading bitmap metadata.
• Why it worked in Windows: x86/x64 architectures generally tolerate unaligned memory accesses through structure casts.
• Why it still works: The bitmap metadata is parsed identically while avoiding architecture-dependent alignment assumptions.
• Why it won't break Windows: memcpy() produces the same values while remaining portable across supported architectures.

Button icon rendering

• Diff: Improved clipping logic, added row pitch calculation, supported both 24-bit and 32-bit BMP formats, and validated image coordinates before accessing pixel data.
• Why it worked in Windows: The previous implementation assumed ideal rendering conditions and 32-bit icon layouts, which generally matched the development environment.
• Why it still works: Rendering behavior is preserved while correctly handling clipped regions and additional bitmap formats.
• Why it won't break Windows: The rendering path for valid icons remains unchanged. The additional logic only improves correctness and portability.

Compatibility

• Existing functionality is unchanged (or breaking changes are explicitly documented).
• MSVC/Windows build toolchain remains fully compatible.
• GCC/Linux build toolchain remains fully compatible.
• No regression in bootloader, kernel, or user-space runtime logic.

Related

Part of #44.

[kheersagarpatel]

Commit: ecb2885

Summary

Documents the contribution guidelines established during the GCC compatibility effort. The new guidance encourages keeping compatibility fixes focused on the minimum changes required for correctness while deferring non-critical improvements through clearly documented TODO comments.

Changes

CONTRIBUTING.md

• Diff: Added guidance to prefer minimal compatibility fixes and defer optional safeguards behind clearly documented TODO comments.
• Why it worked before: The repository did not define a common approach for handling compatibility fixes, so contributors could apply different levels of defensive changes.
• Why it still works: This only documents the contribution workflow followed throughout the GCC compatibility effort. No runtime or build behavior is changed.
• Why it won't break Windows: This is a documentation-only change and has no impact on the codebase or supported toolchains.

Compatibility

• Existing functionality is unchanged (or breaking changes are explicitly documented).
• MSVC/Windows build toolchain remains fully compatible.
• GCC/Linux build toolchain remains fully compatible.
• No regression in bootloader, kernel, or user-space runtime logic.

Related

Part of #44.