Hacking Homebrew Question

[Bri]

How come a lot of homebrew requires that associated data be on the root of the flash drive? I would like to all of my homebrew into folders within a "homebrew" folder on my flash drive, but almost no homebrew will work properly if you do that.

It would seem that in order to be portable, the homebrew should first look for data in the same folder as the .nds file so that it can be moved anywhere on the flash drive and will still work. Is there a technical reason almost no homebrew behaves this way?

-Bri

 

[m-p{3}]

I guess the homebrew data are statically referenced at the root of the volume. I don't know if it's technically possible to change this in the current devkit.

 

[DanTheManMS]

DS files do not have any way of knowing what directory they were launched from. There is Lick's Locater API if the developers wants to search the card for the specific .nds file, but then if someone renamed it they'd be screwed.

Really, it's up to the developer. Some try to put extra data in a folder called "DATA" on the root of your card, to try to help organize things a bit, but not too many people followed along with this.

 

[Bri]

DanTheManMS,

That does explain it. How odd that a homebrew app can't know what folder it's currently in. So how does Colors find its data? Does it search the entire flash card for the "COLORS" folder? I've never tried to move it, assuming that it just looked in the same folder as the .nds file.

I suppose that the "proper" way to do it then would be to search for a folder of a specific name containing the data for your program rather than searching for the .nds file (which is often renamed). It's not uncommon to require that the data folder have a specific name. I'm guessing that must be what Colors does.

If only all homebrew did that (or used a folder within a standard "data" folder) it would make things a lot easier to organize.

-Bri

 

[DanTheManMS]

Once a DS program is loaded, everything else is cleared out of RAM and the program gets full control over all the DS hardware. There's no way to tell it where it was launched from. I believe a functionality allowing for this was added in DevKitARM r21 or r22, but because it relies on every homebrew device manufacturer specifically adding support for the feature, no homebrew has tried using it.

Colors probably uses Lick's Locater to find the "Colors" directory, assuming that you're not going to rename it to anything else.

Really, the DATA folder was a great idea, but it's a shame so few developers went along with it. Keeps things much less cluttered IMO. For example, you can have some settings for DSFTP, Bunjalloo, Readmore, DSAIM, and others inside their own folders in the DATA directory. You can also store the "DSOrganize" directory in the DATA folder if you want, according to the DSOrganize Wiki. I think DS DOOM might also be able to do this, not sure though.

 

[Bri]

Yes, it sounds like every homebrew app should at least support the "data" folder. Anything using Lick's locater presumably already does. It's too bad so many homebrew apps require the data in the root instead of supporting the data folder.

-Bri

 

[DanTheManMS]

At least some, like SNEmulDS, allow you to customize the path by editing a config file (though the config file must be on the root of the card). Perhaps that's an acceptable alternative.

 

[Bri]

Well, the idea was to not have any extra files on the root of the card, but I guess it's better to have one file at the root than lots of files at the root. I still like the "data" folder solution the best (where the app has a single, uniquely-named folder or config file within a "data" folder which is at the root). At least then there is only one folder at the root that is shared by all homebrew apps, and the apps can quickly find their data. I actually like the Lick's Locator approach, but I suppose it's possible that as flash cards get larger it might take more time to find the data file (I haven't noticed any slowdown on applications that use this, but I only have a 2GB flash card). I would think the best solution would be to use both approaches (first look in the "data" folder, then search for it elsewhere).

-Bri

 

[spinal_cord]

I had an idea about this, but it would be up to future homebrew developers to implement it. It would rely on a single file in the root of the card, parhaps called homebrew.ini. This file would simply be a list of homebrew titles and its path. It would be up to the homebrew developers to append their title and path to the file the first time the software is run (check to see if the name is in the list, of not, add it, perhaps using lik's locater to find itself). Then each homebrew can read the list and know where its file are on the card. This way only 1 file needs to be in a specific place, the rest can be anywhere.

 

[Bri]

spinal_cord,

I like that idea, but it would only work if the user is able to edit the file (if it's in a simple text format) in order to change the location/name of the data folder/file for a particular homebrew app. It would also require each homebrew app to have a unique "key" that it would use to look up its data (which is not really a problem since it could use its filename or something similar). Note that this homebrew.ini file could be located in a "data" folder so that both methods could be used (although it would be preferable if there was a single "standard" method). There is also the question of whether multiple paths or other data can (or should) be stored in this file, similar to the Windows registry.

Which brings up another question...I understand that a homebrew app cannot know what folder it's being run from, but can a homebrew app acquire its own filename?

If so, it would be possible for a homebrew app to figure out where it is located on the flash card by searching for its own filename. It could then require its data to be in the same folder as itself. I'm not sure what advantage that would have as opposed to just searching for the name of its data file/folder though (which would allow the data to reside anywhere as long as it has a unique folder or file name).

Another question: What is the overhead involved in searching for a file like Lick's Locater does? I've never noticed a slowdown, but I'm not sure which apps use it and which don't and I don't have a particularly large flash card (2GB). If the overhead in terms of app filesize or search time isn't very large, it would seem that the searching method would be the most robust, particularly as a backup for another method such as the data folder or a homebrew.ini file.

-Bri

 

[Kingwad]

To reiterate the problem, as stated above: When an NDS is loaded, it fills the RAM. it is the ONLY thing running. It has no way of knowing what was run before it (as in it knows nothing the launcher knew). In a system with an OS, where the OS runs in the background all the time (Windows, Dos, MacOS, the Unixes), argv[0] whould get you the pathname of the running file. devkitpro has this feature now (recently) but it requires the card's launcher (part of the firmware) to fill in the value on launch. Since the cards don't do this (because the feature is new to homebrew), this doesn't work yet.

 

[Bri]

Kingwad,

So your answer is "no" an NDS app cannot know its own filename.

-Bri

 

[Kingwad]

Until the cards update their firmware to support argv[0], the answer is no.

 

[Bri]

I tested DSOrganize, and indeed you can place the DSOrganize folder into the "data" folder. On a whim, I tried the same thing with Moonshell, and it seemed to find the data OK. However, when I tried to change some settings from within MoonShell, I then got an error about it not being able to find its data folder although it still seemed to run correctly (it's hard to read the error message because MoonShell launches very quickly so the message is only there for a second). I'm guessing that MoonShell searches for its data file but shows an error if it's not found at the root. Oddly, even when I move the "moonshl" folder back to the root, I still get the error. Can anyone shed some light on MoonShell's behavior?

-Bri

 

[crazyshiza]

Moonshell always puts up that error. If the error stays up, then you have a problem.

 

[Bri]

I'm sure that it didn't put the error up before I moved the folder. Does anyone know why it puts up that error? I wonder if it has anything to do with the capitalization of the filenames of the MOONSHL folder and its contents.

-Bri

 

[Kingwad]

It's puts up the error because IF there's a problem that locks it up it can't display the error AFTER it's crashed. IF it crashes, the error stays up and you can read it.

 

[Bri]

But the error says that the data folder doesn't exist, but of course it does exist. Furthermore, if it didn't exist, it wouldn't be able to find the data, and it does find the data and runs just fine. So...why the error?

-Bri

 

[DanTheManMS]

Like they've said, the message appears for all users of all devices, except if the device manufacturer somehow disabled it (I know a few managed to do it). It's not a message that appears only if it can't find the data folder; it appears briefly even if it can find it.

It's not a problem at all unless it freezes long enough for you to read it fully.

 

[Bri]

I'm sorry, I believe I'm just now understanding what you're saying. The error is SUPPOSED to be there just in case it crashes, and the assumption is that nobody will be able to read it if it doesn't crash. On mine it's up just long enough to read the top line which is an error message having to do with not being able to find the /moonshl folder that I know is there. To me, the current behavior is a little odd and causes a lot of confusion.

If the message is always there (and I could have sworn I didn't see the message before I moved the folder), why not just put the information in a README file under the heading "troubleshooting" or something similar? Or at least reword it to something like: If this message stays on the screen, here are the possible problems...(then list them).

I've never seen an app put up an error message on purpose unless there was an error.

-Bri