libfat returns LFN for 8.3 files in dirnext()

[avenir]

dirnext() returns boot.nds instead of BOOT.NDS, so (also for 8.3 files) you will see the same file name as on WinXP PC.

[WinterMute]

What problem does this patch solve?

[avenir]

WinNT uses reserved flag for filenames with all small characters like "boot.nds".
When there is such file, you can see "boot.nds" on WinNT but "BOOT.NDS" on libfat.
This patch will return "boot.nds" instead of "BOOT.NDS" for such case.

And it seems that I can't see bootlib with decreased size, so I re-attach it

[WinterMute]

I'm still not clear on the problem that's solved here.

What difference does it make? VFAT isn't case sensitive so this is nothing more than a cosmetic change as far as I can determine.

Your "bootlib" patch removes essential functions from hbmenu so it was removed. Please don't post it again.

[avenir]

this is nothing more than a cosmetic change as far as I can determine.

Your "bootlib" patch removes essential functions from hbmenu so it was removed. Please don't post it again.

1. As for NT flag, yes it is cosmetic change, but it is what libelm(Wood/AKAIO) and MoonShell are doing.
[edit]but it is big problem if the software sorts filenames case-sensitive.
But 0xe5 problem is important; if you create a file whose first alias char is 0xe5, the file got marked as "deleted".

2. What do you mean? DSi SD wasn't usable? Here the thumb code bootlib works normally and bootstub was also OK.

[WinterMute]

libelm isn't compatible with libfat and not supported by devkitPro.

What AKAIO, Wood and Moonshell do is mostly irrelevant unless it interferes with the proper functioning of devkitARM and its associated libraries.

Case sensitive filename sorting on a case insensitive file system seems a bit silly but still doesn't seem to be anything other than a minor cosmetic issue.

hbmenu is not a DSi only project nor will modified binaries for specific DS model consoles be provided. The bootloader provider with hbmenu is not a library, nor is it intended for use in normal user code.

Explain the 0xE5 thing in more detail. Under what circumstances does this become an issue? How does the user end up with a file that starts with this character and isn't deleted?

[avenir]

hbmenu is not a DSi only project nor will modified binaries for specific DS model consoles be provided. The bootloader provider with hbmenu is not a library, nor is it intended for use in normal user code.

Explain the 0xE5 thing in more detail. Under what circumstances does this become an issue? How does the user end up with a file that starts with this character and isn't deleted?

1. Actually I have modified bootlib to blink power LED during loading code. The modified bootlib exceeded 40KB and overflew bootstub area. So I needed to reduce the size by using thumb code.
Anyway I'm unsure why you removed my bootlib.patch. It is 90% just Makefile change.

2. Some Chinese character's first byte is 0xE5.

PS. This bootlib.patch contains another patch.
Actually dldi_startup_patch isn't required at all. It will break "homebrew loaded from another homebrew loaded from hbmenu".
"a homebrew game loaded by MoonShell loaded by hbmenu" crashed on AK2i due to lack of actual dldi_startup.
[edit] If you think users won't do that, read sentence again with replacing hbmenu with DSision.

[WinterMute]

1. Actually I have modified bootlib to blink power LED during loading code. The modified bootlib exceeded 40KB and overflew bootstub area. So I needed to reduce the size by using thumb code.

Why? blinking LED is either a cosmetic change or something you use for debugging.

I tried compiling code as thumb a while ago and it failed. The TODO list does have a note on this & the intent to figure out why.

2. Some Chinese character's first byte is 0xE5.

Any chance you could get me a fat image containing files like this for testing?

Actually dldi_startup_patch isn't required at all. It will break "homebrew loaded from another homebrew loaded from hbmenu".
"a homebrew game loaded by MoonShell loaded by hbmenu" crashed on AK2i due to lack of actual dldi_startup.
[edit] If you think users won't do that, read sentence again with replacing hbmenu with DSision.

That may depend on the card or it may be a bug in Moonshell. Some cards fail when the init code is rerun but the card should be already initialised when homebrew is launched. This sounds like Moonshell may well be shutting down the card before launching homebrew which may not be a good idea. While testing the dldi process we found many anomalies in the way cards handle the initialisation of SD cards like the startup code causing an already initialised card to fail and having no dldi section (for cards with default DLDIs that fail on arm7) causing the SD to not start up at all.

This is unfortunately still a really difficult thing to support in a clean and consistent manner, especially when people insist on submitting patches that are only tested on one or two flashcards. Hbmenu has been tested on somewhere in the region of 50 or 60 cards now.

[avenir]

I tried compiling code as thumb a while ago and it failed. The TODO list does have a note on this & the intent to figure out why.

Any chance you could get me a fat image containing files like this for testing?

1. possibly because you didn't compile arm9 part in ARM.
2. later

[WinterMute]

Embarrassingly I somehow read your original patch as removing the DLDI patching which probably confused you about "essential functionality" and "DSi specific" so, oops, sorry. The patching out of startup code is still a bit peculiar, I think I might need to dig out some cards where it failed and see if it can be compensated somehow. Of course we could always just decide not to support those cards where it fails, I do have a vague memory of those being slot2 cards.

I've committed changes to build as thumb now, next thing I want to look at is collating the reads to maximise the number of sectors read at a time instead of the sector at a time approach that's in there now. That's dog slow from the DSi SD due to some odd delays on each read operation.