search

archshift / Decrypt9

Multipurpose content dumper and decrypter for the Nintendo 3DS (SUPERSEDED)
GNU General Public License v2.0
104 stars 84 forks source link

Get rid of the goto instruction in main() #21

Closed d0k3 closed 9 years ago

d0k3 commented 9 years ago

Also, add one line above the main menu for cleaner output.

d0k3 commented 9 years ago

I'd like to add more code improvements via PRs like that and also, to uncouple the decryption functions from the drawing functions to some degree - f.e. now, NcchPadgen has a lot of "Debug" function calls in there, which makes the code badly readable. To fix that, a lot of changes would be needed, and you might not want that.

Just let me know if you are interested, otherwise I won't be insulted and will work on my fork instead. You could still pull what you want.

archshift commented 9 years ago

The change this PR focuses on seems rather pointless, to be honest. goto is perfectly useable for cleaning up after yourself, IMO.

As for the other changes, like adding a single line above the main menu and clearing the right screen alongside the left, those are fine.

Concerning the debug output in the padgen file, I think decoupling decryption from drawing is definitely a good idea though. Feel free to submit a PR :)

d0k3 commented 9 years ago

Alright! I don't know if you have seen it, but I have introduced quite a few changes to my fork: https://github.com/d0k3/CTRXtools

It now includes a NAND dumper and a decrypted partitions dumper. Also, I reorganized the code for a bit, the biggest change being that now all the features (Generate XORpads, Dump NAND, ..) functions are in one .C source file. I did this because I want to create functions for code bits common to several features, and putting those into several .h files will only make it more complicated for now.

Now, I'd much prefer to be able to pull my changes into your repo vs. working on a fork myself and trying to keep up to date. However, there is still the issue with the Brahma loader. I haven't figured out how to create a submodule yet, but I think I could somehow remove and replace with this with the old build system, and keep the Brahma loader to myself (after all, it is seperate from the actual code). Still, my changes are - as I said before - quite big.

My question is... would my changes so far be acceptable for your fork, from what you have read and (possibly) seen? If not, what would I have to change (if that is possible at all)? And are the NAND dumper & decrypted partitions dumper features you'd want for Decrypt9?

archshift commented 9 years ago

Those changes definitely look appealing, although I'd appreciate it if you tried to keep PRs as contained as possible to individual features. Also, looking at features.c on your fork, it'd be best if you kept those structs in a header file somewhere. I'd also like to keep decryption stuff in its own separate subdirectory from everything else.

d0k3 commented 9 years ago

Alright, expect some more pull requests then. I'll try to keep each commit as contained as possible.

Update: I'm closing this PR and making a new one, concentrating on merging your bootstrap fork with my brahma fork.