Efi rework

[kramlat]

What does this PR do?

Type of Change

• Bug fix (fixes an issue)
• New feature (adds capability)
• Refactoring (improves structure/clarity)
• Documentation (updates docs/comments)
• Test improvement
• Other:

Testing

• Tested in QEMU
• Tested on bare metal (if applicable)
• Added/updated tests
• Verified no new crashes/edge cases

Test Environment: QEMU / Bare Metal / Other
Configuration Used: English only / Multi-language / Other

Known Limitations

Any known issues or untested scenarios this change creates:

Checklist

• Code compiles without warnings
• No malloc/free violations
• Comments explain WHY, not WHAT
• Documentation updated (if needed)
• Related issues linked (if applicable)

Notes for Reviewers

---

Remember: This is an experimental system. Test thoroughly, document your assumptions, and don't hesitate to acknowledge edge cases you haven't tested.

[Kelsidavis]

Thanks for putting this together! The EFI direction makes sense, and the genuinely new pieces here — the loader, the OSType helpers, the toolkit placeholders, the build scripts — look like a sensible start. A few things got tangled in the commits though, and I wanted to flag them early. All of them are recoverable.

1. Three files have the "recipe" saved instead of the result

src/FS/vfs.c, src/FS/hfs_catalog.c and include/FS/hfs_types.h currently contain patch text — the lines starting with *** Begin Patch, @@, --- a/... — rather than actual code.

It's a bit like emailing someone the sticky note describing your edits instead of the edited document. The instructions arrived safely; the document just got replaced by them.

The catch is that the previous contents were overwritten in the process:

File	Before	Now
src/FS/vfs.c	~1,425 lines	17
src/FS/hfs_catalog.c	~320 lines	10
include/FS/hfs_types.h	~215 lines	19

So most of the −2,162 lines in this PR isn't the PowerPC cleanup — it's the file system layer disappearing by accident.

Since patch text isn't valid C, the build stops as soon as it reaches them:

include/FS/hfs_types.h:1:1: error: expected identifier or '(' before '--' token
include/FS/hfs_types.h:3:1: error: stray '@' in program
include/FS/vfs.h:19:62: error: unknown type name 'VRefNum'

...and then cascades through everything that includes those headers.

Suggested fix: restore those three files from main, then re-apply the intended edits directly. The real changes look small — keeping printable creator/type strings in sync via OSTypeToString, and the UTF-8 name handling — so it should be a quick redo rather than a rewrite.

2. One script lost its "executable" flag

scripts/check_tool_versions.sh changed from mode 755 to 644, meaning the system no longer treats it as something it's allowed to run. The build stops on its very first step with Error 126 ("found it, but not allowed to run it") before compiling anything at all. I had to work around it just to reach the errors above.

chmod +x scripts/check_tool_versions.sh
git add --chmod=+x scripts/check_tool_versions.sh

3. Emptying grub.cfg will break the boot tests

CI builds a bootable CD image and boots it in an emulator two different ways — old-style BIOS and modern UEFI — and checks the system actually reaches its main loop. Both of those still rely on GRUB, so with grub.cfg emptied they'd fail even once the code compiles.

Probably worth keeping GRUB working until the EFI path can boot on its own, and removing it in the same change that replaces it, so there's never a commit where neither works.

Why none of this got flagged automatically

CI hasn't actually run on this PR — GitHub is holding it for maintainer approval since it's a first-time contribution, so no checks ever fired. Definitely not something you did wrong; there was just no automated feedback to catch any of it.

One question

docs/HANDOFF_DEEPSEEK.md refers to kramlat/LazarusOS and reads like notes for handing the work to someone else to continue. If this branch is mainly a working handoff rather than something aimed at merging here yet, that's completely fine — just let me know and we can leave it open as a WIP.

Happy to help with any of the above. Thanks again for digging into the EFI work.