Homebrew Collection of old devkitPro versions

[dubbz82]

Open source libs are bound to change because it's simply not enterprise grade software where you can expect compatibility back to the last century. It's not doable.

I get that. And any open source developer that wasn't a stark raving lunatic would too. It's why it should work like every other open source project I can think of where you can simply grab old releases and use them as you so deem fit. At your own risk and potentially with bugs. Hell even most commercial grade software isn't this strict with their software and allows for older versions to be used.

 

[Ryccardo]

So, while the "official distribution" is perceived as lacking, otherwise unsatisfactory, or nonexistant due to legal limbo - piracy solves the consumers' need, not-so-rarely better than the official way

Who would have guessed that outcome, on a console modding forum?

 

[leseratte]

piracy solves the consumers' need, not-so-rarely better than the official way

This is not piracy, as devkitPPC is under GPL and the binaries identical to the officially released ones.

 

[Brawl345]

not-so-rarely better than the official way

And ironic how we use homebrew to "free" us from Nintendo only to have another one who tells us what to. And with a lib that's basically half-stolen from the official SDK.
It's just an option to use the old version, not everyone has the time/knowledge to update all this stuff and nobody can force it. The time wasted with arguing about this could be better spent elsewhere. Thanks for the archive Leseratte. Don't know why WinterMute is so stubborn with devkitPro stuff

 

[FAST6191]

Some interesting goings on here.

On the face of it trying to incentivise updating projects is not a bad thing.

However attempting to remove the means for someone to come in and do minor changes, possibly even those without many skills, is a step too far for me.
Many times I have had people cross my path that wanted something translated (not everybody supports full unicode external resource files, especially not in console homebrew of that era). To tell some would be translator "no, you have to learn programming" rather than "this file which is essentially a text file, translate accordingly, run this command line command (just copy and paste) and enjoy your end results".
There are other times when people have wanted to refine play -- change a few multipliers, comment out a given mechanic... and you can have a radically different game. I have seen this many times and it knocks it back to down to "follow through this fairly logical mathematical progression, copy paste this command and enjoy". Tacking on a "also you will need to do a debug session"... nah.
Going further "find a project you enjoy and play with that" is something we have seen routinely when people want to learn programming around here, and while learning things would appear to be the aim of the game it likely joins the same thing that sees some people turned off by the command line compilers not having the fire and forget type option.

Moreover when seemingly one of the goals of the tools in the first place is "so people that aren't http://www.catb.org/jargon/html/story-of-mel.html can stand a chance of doing some decent homebrew on a console" it seems rather opposed to that notion. Further arguing that people should be expected to have skills and that things just might be lost... that is pretty much the opposite of what we do around here (other than playing games if there are three things we hold dear around here it is preservation of games, twisting of said games to our own ends and making the devices dance to our own tune). You are not going to get terribly far arguing against that.


Trademarks then. I don't know if you are attempting to use this as an end run to help provide said incentive (a rather amusing notion if so given "running stuff one consoles" is the aim and the well documented past actions of the console makers, and likely current actions if they stood a chance of accomplishing anything) or are actually attempting some kind of trouble prevention.
It is not the first time we have had devs be troubled by old version mirrors of their work causing some kind of support headache and we have attempted to accommodate them. Most of those were "no functionality changes, purely bug fixes" scenarios so not the same the same as here.
First where are these trademarks? I checked the UK (which will reach out for the Europe wide stuff) and US trademark registries for devkitarm, devkitpro and devkitppc and came back completely empty (no current, expired or similar) and no mention of them on the websites. Trademarks are a register only affair (no inherent/automatic protections like some aspects of copyright and design rights) and falsely and maliciously claiming one would be terribly poor form. For the sake of civility though we can probably arrange for some other name to be used, and note them as devkit* version ?? compatible by some means not likely to trouble search terms.

Copyright then. If I am to understand it the original works (released under various flavours of open source licenses, though mostly GPL) got packaged into binaries of some form and that is what the OP (and other previous people) have attempted to mirror. Many such licenses demand the source to programs be made available to its users (some interpretation and generally as people like open source they quite literally make it available in easy form to anybody that wants it). For whatever reason though does it appear that version control went up in a puff of smoke* and nobody made timely snapshots of everything relevant to each build (few thought to do that, even I looked at it, saw something coming and still did nothing on most occasions and even with my archives have come a cropper a few times already in the DS world) as might be technically demanded by the licenses, and for whatever you actually own the rights to you intend to put the boot to the proverbial neck of any would be mirroring types?
That would be terribly unfortunate and garner you no small amount of ill will but it is not the first time we have had to work around such issues.

*being sourceforge and not something nice like git I am guessing none of those nice rewind to literally any level of commit up to the point where you last updated either.


Others playing along at home then. What is the functional requirement of each DKP version? I have not had cause before now to really look into the devkitppc side of things but my understanding is there are mostly libraries (usually not solely precompiled so inherently with available source), the compiler (not sure how custom this is), the assembler (for the arm one it is often what I pull one from and I believe it is largely borrowed from other projects), build scripts (also not sure if plain text and thus inherently source available) that provide most of the functionality. There are certainly tools (occasionally external, often not), example scripts/projects and such which would be nice to have but for most purposes would not be needed, or can be filled in later, not to mention later versions of which may well be compatible or with source they do have made compatible with the older versions.
My suggestion for orders in which to try to achieve some kind of... "binary compatibility" would be on the basis of popular or likely to be useful homebrew and filling in the gaps from there. It is a lot of work, redundant at that, but hey.

 

[leseratte]

Many such licenses demand the source to programs be made available to its users

That depends on how you define "source". The GPL defines "source" as "the preferred form of the work for making modifications to it".
As it is claimed that the original source is lost, the binary is the only form of the work available anywhere, and thus, for old versions, indirectly has to be "the preferred form" as there is no other. You can edit and modify a binary, too, which is basically done in the wii scene a lot anyways (think of game cheat codes), it is just not as convenient as with source code.

 

[FAST6191]

Interesting argument. I have not really met that one before (then again I have not met lost source in open source world outside of I think it was an old backup tool that had been going since the 80s, they mostly being interested in history, and I think it was depan which got DMCAed or something before people got into making backups of such things) but it stands to some reason.

As for editing binaries the cheat code thing tends to fall under other aspects of law (world of warcraft having some fun ones, though probably covered under the galoob thing way back when), to say nothing of usually being done in your own private setup (see also where companies will hire coders in to make juiced up versions of OS programs for in house use).

 

[leseratte]

Yeah, I wasn't trying to start a discussion on the legality of cheat codes in public games, only on the fact that cheat codes are basically rewriting a binary program and thus it is possible to do so in cases where source is not available, as it is the case here.

 

[NightScript]

So actually you don't disagree.

Actually, I do.

Spoiler: Random analogy with a childrens book

Have you ever read this book called the city of ember: The prophet of Yonwood? I had to read it for a book report, and now I know why. My teacher did tell me that the moral lessons of the book apply here, and look where I am.

In the book, there is a girl called Ms. Breeson that tries to make everyone "do what god said" and have a perfect world.
That is comparable to you saying that all the devs should update their applications.

I don't want to spoil the book for those who didn't read it, but in the end, there is a convo where two characters (not saying names for spoiler reason.) say the following conversation:
"Lady 1: That lady (Ms Breeson) has her notions
Lady 2: she wants the town to be perfect
Lady 1: In this life, you don't get to have things perfect. Life is messy, no way around it."

Now, lets change a few words to fit in with what people would say about you if you continue acting like this.

Random 1: WinterMule has his notions
Random 2: he wants the development environment to be perfect in his eyes
Random 1: In this life, you don't get to have things perfect. Life is messy, no way around it. You can't force people to do things that will annoy them.

The fact that I had to use a childrens book to prove you wrong is just how sad this whole situation is. I could have easily proved you wrong another way, but I decided to use this because the type of book I picked represents your behavior. Plus, no one is more comparible to the main villain than you

Spoiler: A more natural approach

See, here's the thing WinterMule: you can't always get things the way you want it. Why do devs have to stay in hiding because they are using old tools? Why should they stay in hiding in the first place?

You're trying to make the community better, but you're actually making it worse. The fact that you had to update PufflePaddle3DS manually just proves how bad the fact that you won't let us do it ourselves are. Why not just do what literally everyone here is requesting, and stop going after old builds?

I understand your whole deal with making sure people use your latest tool to see your latest work (heck, I already get mad that not people use MakerBoard), but not if it breaks old works that developers spent hours into. How would you feel if you made an amazing game, but no one can play it because there is no built version of it, and your codebase is no longer maintained and is meant for an old version of a tool? You would feel devastated, right?

This assumes that building homebrew without programming skills is a reasonable expectation in the first place.

Actually, it is. That sounds pretty normal to me

 

[realWinterMute]

Why do devs have to stay in hiding because they are using old tools? Why should they stay in hiding in the first place?

They could ask for help if their projects won't compile with latest tools. Funnily enough we have a lot of experience doing that. Crazier still we don't mind helping people.

You're trying to make the community better, but you're actually making it worse. The fact that you had to update PufflePaddle3DS manually just proves how bad the fact that you won't let us do it ourselves are. Why not just do what literally everyone here is requesting, and stop going after old builds?

I didn't have to update it, the person who requested it could have done that, with ease. I did it to illustrate that minimal changes were needed to get it to compile against latest libctru. I also did it because it's suitable for another little experiment I had in mind but you'll find out in due course.

Had someone asked in the right place though it would have been a few minutes work - much less, in fact, than attempting to reconstruct the tools of 2014.

It's showing people how to fix something. Somebody somewhere looked at what I did and learned something they may well be able to apply to another project. Just throwing old tools at the problem is actively preventing people from learning.

I understand your whole deal with making sure people use your latest tool to see your latest work

That's not what it's about.

I see users flung into a hell hole of incompatible libraries on a daily basis. Quite often the reasons things no longer compile with latest tools are simple misuse that compiler diagnostics didn't catch before. Sometimes it's because the gcc or newlib headers have been changed to conform with standards and now some define is required to enable particular functions. Easily fixable things for those with experience, insurmountable barriers for novices sometimes.

This is about trying to encourage an environment where newbies aren't instantly flung into a massive hole from 2003 simply because nobody has asked for help in the right places. It's about spreading the knowledge needed and trying to get people to stop just throwing old archives at a project until it compiles & calling it a fix.

How would you feel if you made an amazing game, but no one can play it because there is no built version of it, and your codebase is no longer maintained and is meant for an old version of a tool? You would feel devastated, right?

I would fix it though, call me crazy ¯\_(ツ)_/¯

Crazier still, if people come to me with broken projects I'll often do my best to help them fix it. I'm only one person though, I could do with more people willing and able to make that effort and ultimately that's what I'm trying to achieve.

Actually, it is. That sounds pretty normal to me

That's not really how reasonable expectation is defined.

I also think you're somewhat missing the point that devkitPro toolchains exist in order to make things easier. The fact that you have the expectation that random homebrew can be compiled with little effort is largely due to our efforts. You're missing pre devkitPro experience.

--------------------- MERGED ---------------------------

- You are not providing source for old binaries, for example for devkitPPC r28 which has been distributed within the last three years. That violates the GPL, section 6(b) as well.

You're not allowed to distribute binaries you can't provide the source for, complying with GPL requires that the binaries are removed.

What part of that is hard to understand? I removed all binaries I can no longer supply source for and builds that can no longer be replicated in compliance with the GPL.

 

[Cyan]

It's showing people how to fix something. Somebody somewhere looked at what I did and learned something they may well be able to apply to another project.

Is there a place which explain each changes needed to be done to compile after an updated toolchain?
I remember going from ppc r27 to r29, the compiler now detected conflicting variable size, and you could fix it by casting the proper size or properly matching them from a function to a variable.
u32 var;
s32 function() { return s32 value }

var = function(); <-- this gave an error/warning, even if you new the returned value would be fine, or if you wanted the signed output to be seen as unsigned for the var.

you could either change the var to be s32, the function to return u32, or cast it to u32 keeping the return function as s32.

that's just one of the example, and I wonder if all the changes are listed somewhere with information for the developers to learn what to do and how to update their projects ?


Like you said, the change you did can benefit someone else, given he can find it and understand what you did, and if there's a single place to find all changes and necessary knowledge, that would be nice.
something like a changelog for developers. (Mozilla did that for each update of firefox, for developers, and help was provided to upgrade to all changed functions and new features, instead of that do it this way, etc.)

edit:
I wonder if I'll have this problem too. https://github.com/devkitPro/installer/issues/11
I'm on win7 and never launched IE.
I wouldn't like tools to edit permanent OS settings without my knowledge. if you fix it by forcing the installer to change something, put it back once done? or inform the user to do it and explain why. If you fix that issue, I'd prefer a warning with an explanation of the problem, but that's just my view, like I said I often fear the unknown and don't like changes without knowing the outcomes.

 

[leseratte]

I wouldn't like tools to edit permanent OS settings without my knowledge. if you fix it by forcing the installer to change something, put it back once done? or inform the user to do it and explain why. If you fix that issue, I'd prefer a warning with an explanation of the problem, but that's just my view, like I said I often fear the unknown and don't like changes without knowing the outcomes.

From that issue report, how do you come to the conclusion that the installer does edit these settings? This is just a report of the installer failing, and the user manually setting these settings to make it work.

 

[Cyan]

I do not.
I just make supposition for a future, possible fix, that IF he will go that route and modify IE settings to make it work I would prefer to know what is changed.
that's just hypotetical. It's not doing it right now, because the issue is not fixed yet.

I said "IF you fix that issue that way, I'd prefer to know it". there are probably other ways to fix it.

 

[BullyWiiPlaza]

This is indeed interesting. I also noticed that newer devkitPro versions might break existing code bases. This isn't such a big deal though, the errors usually indicate the problems quite clearly so by changing a few small pieces in the code it should recompile and everyone will be happy. Let's enjoy the new compiler features and improvements. It's usually a good thing and you'll save the trouble for everyone else who wants to compile it again some time in the future. It does get concerning if there are showstopper bugs in the compiler though but I haven't really noticed any so in that case just report them and in the meantime you can use the previous build or find a work-around.

 

[dubbz82]

This is indeed interesting. I also noticed that newer devkitPro versions might break existing code bases.

Not just "might". This happens. A lot. Otherwise this thread likely wouldn't even exist. The really big problem isn't when you're trying to jump a single version usually though, it's more often when you're trying to bend a chunk of homebrew from say 2007 to fit your needs. For doing these sorts of things it makes a heck of a lot more sense to grab up an old version and compile your project than it does to sinking hours into refactoring the project, especially if the changes you're trying to make are simple. Now granted if you're actually intending on reviving a dead project for non trivial changes, yes you should update your toolchain and refactor accordingly. If you're fixing a typo that's gone unnoticed though it's an awful big ask to have someone be forced to update the toolchain and all associated code for something that simple. That's really what the whole purpose of this thread is.

 

[PrincessLillie]

I removed all binaries I can no longer supply source for

Except you could provide the source for them. You just chose not to.

 

[realWinterMute]

Except you could provide the source for them. You just chose not to.

The source could not be made available, it no longer existed.

Please try to understand that a full installation of devkitPro toolchains and their associated libraries consists of 100s of components which all interact in various ways. Attempting to reconstruct the particular set used to build a particular project is an exercise in futility - even if you know what versions of the components were current at the time of the last build you can't know what versions of the components were used by the original developer. There is at least one project I'm aware of where the original developer backported library updates to old versions rather than update normally because the binary failed to work when compiled with versions of one particular component after a particular version. No versions of the tools and libraries used to construct that particular build ever existed outside one particular hard drive and cannot be reconstructed.

Now, had that particular developer actually brought the problem to our attention at the time instead of almost 2 years later then we *could* have fixed it then and saved a *lot* of heartache.

On the other side of the coin there are 100s possibly 1000s of homebrew developers who have spoken to us directly about an issue and obtained help before digging a massive hole for themselves.

Keeping up with toolchain & library updates *will* improve the experience for *everyone*. Stubbornly refusing to countenance fixing broken code and childishly creating a repository of every archive you can find however tenuously related to our work just exacerbates the problem & creates a culture that impoverishes everyone victimised by it.

 

[FAST6191]

I still maintain the cases of translations, simple tweaks and people learning to code (be it with existing projects or more legacy tutorials) more than represent good reasons to keep old versions around and not force people through a debug session to get it to compile again. In an ideal world everybody would have the skills, time and inclination to update to current but it ain't an ideal world, and if it was homebrew would not be a thing as everything would be open already. Kudos on offering a service/assistance in getting things up to date but it is far from the only way*.

A complex interaction of many pieces it may be, and if you insist on blocking old revisions from public sharing I would have to ask how much of this interaction is necessary -- not every program will use every operand and as such you could probably skip non essential components, use current versions of tools.
Making some kind of piecemeal replacement is far from ideal, and definitely a worse solution than "keep old versions of toolchains around to build against", for reasons likely blatantly obvious to both of us.

I similarly don't see how it is childish to keep old things around. Archival of things is typically considered a righteous thing in these circles, especially if the only problems likely to occur are rather abstract ones (not like there is unintentional bricking or otherwise "malicious" code in the older stuff) like people having less incentive to update.

Can I also ask what is the name or general purpose of the tool if you have since forgotten the name that is causing these issues? If we can make a suitable replacement for those one or two things, or even just remove them (we could even promise not to "strongly hint" if they care that much), then that would be far easier.
Does this developer/project with lost source really care about such things as well? Most devs I meet are usually happy enough for others to be using their tools to have a good time. While technically non compliant, especially if compliance is now "impossible", it is not really something you are compelled to pursue and even if it were then trying to determine "harms done" would be a nightmare -- person uses tool you made and released for free (or effectively so) to in turn make another thing for free (usually anyway).

*indeed going back to the thing earlier where I pondered getting popular projects and making things for those to compile. A solution might be to create such a list (we saw something similar with the introduction of DLDI on the DS, and a minor variation later when some of the later refinements to DLDI happened) and work accordingly. Would probably not be the most productive use of time (we have a trivial solution already) but would be a solution to most of the problems.

 

[BullyWiiPlaza]

Not just "might". This happens. A lot. Otherwise this thread likely wouldn't even exist. The really big problem isn't when you're trying to jump a single version usually though, it's more often when you're trying to bend a chunk of homebrew from say 2007 to fit your needs.

Why would you even revive an 11 year old project when nobody cared for all this time?
Either 1) it's fine and there is no need to recompile it or 2) your changes are pretty meaningless so you might as well don't do them or 3) you want to perform impactful changes so you're running into the issue with newer devkitPro versions

Each popular project should gradually be updated to compile on the latest devkitPro. If this doesn't happen, apparently it's not that important and if you really want to bring it back anyway just invest a few hours to get it up-to-date with newer compiler standards. Clearly some poor code was written so it's about time to fix that as well. It's the same on other platforms like Linux/Windows etc. But honestly, it's not like the people affected by this are short on time, still messing with Wii stuff intensively is kinda no life-ish in 2018 so it's nothing in comparison to the time invested doing all the other coding stuff surrounding it lol. Just deal with it, Wintermute explained it detailed enough. You can't have it "your preferred way" and it's a small fraction of time which pays off as well to improve everyone's experience in the end. Wintermute's support effort becomes exponential when all random old versions are still being used. This isn't a toolchain supported/made by 100's of people.

 

[KirovAir]

But honestly, it's not like the people affected by this are short on time, still messing with Wii stuff intensively is kinda no life-ish in 2018 so it's nothing in comparison to the time invested doing all the other coding stuff surrounding it lol. Just deal with it, Wintermute explained it detailed enough. You can't have it "your preferred way" and it's a small fraction of time which pays off as well to improve everyone's experience in the end. Wintermute's support effort becomes exponential when all random old versions are still being used. This isn't a toolchain supported/made by 100's of people.

This argument is bullshit. Let's say (and this is from my own experience) I find a piece of homebrew from 2007 which hardcoded uses memory card slot A as SD gecko file interface. I want it to use slot B because slot A is my normal memorycard. It's simply a 1 character change and a press the compile button in order for me to change it to slot B.
Updating everything to today's standards would cost so much unnecessary time which I simply do not have. And trust me, I love coding and all. But I code every single day at the job, so less is more during spare time.