Homebrew How to code an installable channel?

[BullyWiiPlaza]

One could keep on allocating, but when you consider that HBL only has a little under 8MB of space available you'd start to run out fast. I can't speak for why dimok designed it this way, but I do think that it makes sense when you consider that without extra fiddling, HBL apps will return to the launcher menu rather than the home menu. It was clearly meant to run an app, quit to HBL, then run a different app. I wonder if HBC does this? That seems to be where HBL's inspiration is from...

(random side note: the blue menu with all the homebrew is actually a HBL application, just like any other. There's a backend that's totally separate which handles all the ELF stuff)

I wanted to do encryption of bytes sent/received for performance reasons but it will never work since the memory necessary for the cryptography to work exceeds the one available so duh, we need more memory. Why just around 8 MB and not much more though?

 

[QuarkTheAwesome]

encryption of bytes sent/received for performance reasons

Let me stop you right there...
Encryption is always going to be slower than just the raw bytes, because you need to do some extra maths in order to encrypt/decrypt it. The hit might be negligible, but it's never going to be faster than sending the raw bytes as-is. Did you mean compression? The 8MB is for the application ELF - you can still allocate memory from the main heap; if you've got malloc wrapped properly you can even do it transparently.

 

[Maschell]

I wanted to do encryption of bytes sent/received for performance reasons but it will never work since the memory necessary for the cryptography to work exceeds the one available so duh, we need more memory. Why just around 8 MB and not much more though?

Isn't AES designed to be super lightweight? It should just need a couple of KB

 

[BullyWiiPlaza]

Let me stop you right there...
Encryption is always going to be slower than just the raw bytes, because you need to do some extra maths in order to encrypt/decrypt it. The hit might be negligible, but it's never going to be faster than sending the raw bytes as-is. Did you mean compression? The 8MB is for the application ELF - you can still allocate memory from the main heap; if you've got malloc wrapped properly you can even do it transparently.

Yeah, I meant compression of course to speed it up. @Onion_Knight said that it works well (for the browser version, he never released any source code or build though) but e.g. zlib always runs into memory errors when I tried it. I don't know why but the TCP Gecko installer is already at its limit of memory allocation e.g. there is not even 1 KB left even though everything is deallocated as it should and buffer sizes are not chosen unreasonably high. Zlib needs at least 260k to function so it will never work.

Isn't AES designed to be super lightweight? It should just need a couple of KB

Still out of memory for above reasons. Maybe I'm missing something and someone else should investigate.