Why would you revive an old project? To translate it. To modify it to suit your needs. To correct a bug. To fix a typo. The list goes on and on. Also your implication is that all well written code from say 2007 should compile in modern toolchains without modification. That's not only untrue but a flat out lie. Some people also just prefer to compile from scratch as opposed to using rebuilt binaries (and with some projects rebuilt binaries aren't a thing through official channels).
Why would you revive an old project? To translate it. To modify it to suit your needs. To correct a bug. To fix a typo. The list goes on and on. Also your implication is that all well written code from say 2007 should compile in modern toolchains without modification. That's not only untrue but a flat out lie. Some people also just prefer to compile from scratch as opposed to using rebuilt binaries (and with some projects rebuilt binaries aren't a thing through official channels).
Paths aren't always plaintext (binary compression and packing was not as common on the Wii as some other systems, ones also handled by DKP, but was hardly unknown), might have dozens of references within a piece of code, and thus you are into a debugging or hacking session. As it is not necessarily just a path either and might warrant some IO to liven it up from a different function...
Similarly while it was an example on the simplest side there are plenty of things which would benefit from a 10 second go in notepad++ and a recompile. For the DS but I was once playing tester for someone doing a build of DS doom to work with DLDI. A simple directory change (so you did not have to have the files scattered across root) saw fairly significant changes across the binary, and if someone decided to hardcode a now dead url and your replacement does not match length... I already mentioned wanting to tweak multipliers for games, or maybe slightly tweak a filter for an emulator (when playing with scaling filters I tend to favour a few different limiters than the default ones people go in for).
This sort of thing we see fairly often (typically someone comes in knowing say python or java, so reasonable idea of program flow, what coding syntax looks like in general but terribly unlikely to be able to do a C hello world from their walking around skills), or do ourselves (hounding a dev to do small almost cosmetic changes, or changes outside their preference/vision, is not great form).
At this point I would probably go grab a changelog for the main libs in the kit (and all the other versions) and have a look. Bets on a function changed such that someone with a basic idea of coding could do some of the stuff above but might not know how to parse a function call properly, or worse still would get it to compile on a newer one, compile validly and then suffer unexpected behaviour because something in the function call was null/defaulted to behaviours not expected. All of which would be a null problem if they just had a choice version of devkitpro that the original dev would have had all those years ago.
I'm aware of the limitations. He mentioned changing a single character which is easily done with a hex editor. If paths are not just strings or the resulting string is bigger than the original it's easier firing up GCC. It's all about choosing the right tools/methods to get the job done but i generally agree to rather update the codebase. APIs change and it's often easy to fix old code.
And a word on compiler warnings: Newer GCC versions are getting better detecting possibly broken code. Just because no warnings appeared with older versions doesn't mean there is no problem. Please don't ignore warnings because they more often than not point to problems. C/C++ offers a million ways to shoot yourself in the foot and bugs are often enough not obvious unless you know the pitfalls.
And a word on compiler warnings: Newer GCC versions are getting better detecting possibly broken code. Just because no warnings appeared with older versions doesn't mean there is no problem. Please don't ignore warnings because they more often than not point to problems. C/C++ offers a million ways to shoot yourself in the foot and bugs are often enough not obvious unless you know the pitfalls.
Would be way easier to just hexedit the binary in that case.
This is the part you don't seem to grasp. We don't release 100s of components in one single package, everything is updated as required. If one component has changes (i.e. devkitARM) with knock on effects on others (i.e. libnds + default arm7 binary) then those components are released simultaneously. At some points other libraries compiled against libnds might need to be rebuilt (i.e. dswifi, maxmod). It's fairly involved sometimes & can be difficult to get right. It can't be reconstructed piecemeal and we can't supply a snapshot for every change we make. What people are asking for when they want a set of tools and libs to compile a particular project from, say, 2009 is much like asking for a reconstruction of a particular linux box at a particular point in time.
That's the thing though, some of the binaries in there actually are malicious. Installers of 3rd party things that depended on devkitPro toolchains & libraries thought it would be a fantastic idea to carry the version of libnds they needed to build their code. Using that installer on any installation of devkitARM & associated libraries will render it incapable of building the supplied examples & produce non functioning binaries when used to compile apps which use the 3rd party library. There were also a couple of "joke" default arm7 binaries kicking around that bricked the DS they ran on. Some other components are detected as trojans due to being the versions that were used to compile the infamous ds bricker and any .nds built with those will be deleted by several antivirus products.
In any case, the fact that this exists at all means that people can and will fall headlong into the trap of attempting to make new homebrew using old tools & libraries and dig themselves a hole they can't climb out of.
Primarily repositories of random binaries and tutorials written by people who don't know what they're doing. I've just walked someone through fixing a switch toolchain installation which could no longer compile code after they followed a guide from this very forum. The specific project I mentioned has long since ceased to be maintained & the original developer moved on. I'm not aware of anything still currently active that's really quite that bad.
This is a much better idea than providing historic archives that can't even really be used to reconstruct a toolchain installation properly. If there are devs around willing and able to get old projects building & working with current tools and there are users around clamouring for changes to said projects that can only be achieved by recompiling then a means to connect those groups would be good.
Again, devkitPro is an organisation, not software. We build and maintain a lot of software useful for creating homebrew. We do it in a particular way that gives a novice a good chance of building current homebrew projects (and even many historical ones where the developers used a stock install & kept up with updates.)
The *only* place you can be guaranteed to get the particular set of components used to build a particular project from a particular time is from the original developer's hard drive. We can't supply that, nor can we comply with the license requirements for distributing such a bundle. Nobody can.
Great work, an archive was really needed.
To be honest, I had now a project that for 3 months which I wanted to modify a little part of it, and the fact that all old releases got wiped just made me don't do so. Now this saves a lot of time I can do it, thanks a lot laseratte for your initiative! And sure we thank most of all WinterMute for developing these great tools.
But...
WinterMute we're not asking you money or anything! If someone wants to choose to use old toolchains, it is just his sole responsability, and if the binairies he build are infected by anything due to that he just assumes his responsability, like every developer. We're saving your time, do you imagine if anyone ask you for help for a homebrew he wish to change something and will be probably the only user of it? I just don't want to ask help for things so negligible, time is valuable for everyone (and asking always for help can become a very bad habit).
Also, please put yourself in others place. I saw 2 times you were referring to fixes "YOU figured very quickly" and straightforward. But we don't have your experience lol! It is not because YOU spent 30 seconds to fix something that it will not take 3 hours for someone else not so experienced. laseratte is far from being selfish.
To be honest, I had now a project that for 3 months which I wanted to modify a little part of it, and the fact that all old releases got wiped just made me don't do so. Now this saves a lot of time I can do it, thanks a lot laseratte for your initiative! And sure we thank most of all WinterMute for developing these great tools.
But...
WinterMute we're not asking you money or anything! If someone wants to choose to use old toolchains, it is just his sole responsability, and if the binairies he build are infected by anything due to that he just assumes his responsability, like every developer. We're saving your time, do you imagine if anyone ask you for help for a homebrew he wish to change something and will be probably the only user of it? I just don't want to ask help for things so negligible, time is valuable for everyone (and asking always for help can become a very bad habit).
Also, please put yourself in others place. I saw 2 times you were referring to fixes "YOU figured very quickly" and straightforward. But we don't have your experience lol! It is not because YOU spent 30 seconds to fix something that it will not take 3 hours for someone else not so experienced. laseratte is far from being selfish.
Last edited by iyenal,
- Joined
- Nov 28, 2013
- Messages
- 2,921
- Trophies
- 3
- Age
- 21
- Location
- Virtual Earth
- Website
- lillie2523.carrd.co
- XP
- 4,790
- Country
It no longer existed because you deleted it. Updating an application does not require you to delete the old binaries and source code, as evident by the literally thousands of other applications developed by the community.
This is likely the exact reason this archive was made.
If it was meant to improve the experience for everyone, then it wouldn't break applications when the devkitPro libraries are updated.
And yet this wouldn't be needed if your applications had better backwards compatibility.
No, it wasn't.
What is this project? Did you try compiling it with new tools? Did you ask for help if it failed?
You're doing the precise opposite though. This stuff breeds and I end up spending more time helping people fix problems that were caused by people chucking random things in their toolchain installation.
Ask for help, we'd rather you did that than end up buried in a massive hole someone else dug you into.
This is kind of the point. Ask for help, it may well be that I can supply the solution in a few minutes & save you months of heartache later.
Childish and short sighted. Absolutely. Supplying these archives encourages people to mess up their toolchain installations instead of asking for help. By the time they dig a big enough hole to be forced to ask for help they're in too deep to be helped.
No, not really.
Inited strings goes to DATA section:
https://gbatemp.net/threads/anyone-know-c-quick-question.517505/page-2#post-8270130
now, depending on the system, it may go to RODATA or TEXT section (if you tell the linker to do so). There's no hint for the compiler except the exact same size the string was allocated (if you use -03, the string size might be hardcoded on the string operations, instead, if, say, you used strlen to get the string size. If you reverse engineer games, you will find these are seldom compiled with optimizations in mind since it causes these kind of issues, (and that's why you can hijack POSIX string functions to generate exploits)).
So changing the character through hex editor (without having reverse engineered the code earlier) is not as close as effective as rebuilding the project, and dealing with other possible bugs as well, you will only generate undefined behaviour.
The problem is newer GCC is optimized to generate better code for updated processors, not for older processors. (ever heard of GCC breaking opcodes on legacy processors, when adding features/tweaks to newest ones?)
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/416188.html
(armv4t, the ARM7 found in GBA/NDS/3DS is the oldest supported ARM processor, and it does not generate anymore code for ARM/THUMB state depending on the bit 0 of the ARM prefetch unit points to, instead it uses the BX which is supported on ARMv4t , armv5te + processors, and that's just for the time being. Can't wait for GCC devs to deprecate these processors, and truly the hardware will suffer from bitrot or unexpected behaviour, adding more bugs on top on latest GCC). Thankfully we still have ARM embedded toolchains, but I know these devs only support newest processors as well (possibly for $$$$ reasons). So that leave us with legacy GCC that DOES NOT generate issues on older processors such as the GBA/NDS.
Also what GCC devs have managed, was to let the linker adapt binaries for different ABIs through arguments, even if the GCC compilers don't generate such code. That will definitely add weird issues. Such as above, if you don't specify
--fix-v4bx to the linker, it will generate ldr pc,=0xe7xxxxxx code which works on ARMv4 processors, but these do not support THUMB interworking (the code generated isn't compatible with BX rx), effectively breaking support on even ARMv4te processors. As I have experienced myself by using newest GCC. ARM7 Code in ToolchainGenericDS broke, so I had to downgrade and use the above workarounds around a relatively new GCC environment compiled for ARM cores.
My take on this is since GCC is aiming to support only the newest processors, is to build a stable GCC revision per platform, rather than force every platform to latest GCC as that will undoubtedly cause very, very hard to debug bugs that come from the linker (and for every newest GCC revision being already a pain in the ass to debug).
Last edited by Coto,
Honestly...no you shouldn't spend a bunch of time trying to help people running old toolchains. Simply ask if they're on the latest updates. If not simply answer that older versions are unsupported as literally everyone else that's ever written software ever would do. The only thing that's childish is acting as if you're the one and only authority when it comes to other people's projects and how they do/don't choose to build them. If someone opts to use old tools and their projects break because of it? Well that's entirely their own fault and they should be responsible for correcting it on their own. That being said, trying to force people to use whatever toolchains you are currently using is not only childish but also very much self centered and as many people have confirmed even problematic at points.
ok, this has gone too far.
Is he not allowed to update his applications just because it may or may break other applications?
Look, while he should keep adding new things to his new versions, he should keep the old things. I have no problem with WinterMule breaking old things with new version as long as the old version are still up. Now there lies the problem.
Yeah, I agree with this.
because it STILL supports AT LEAST armv4t (and not any below ARM processor), can't wait till GCC deprecates ARMv4t
edit: and that's because that certain GCC distro caused ARMv4t issues. I have no problem recompiling toolchains, it's dead easy.
Last edited by Coto,
First of all it doesn't matter where it's stored. Second it doesn't matter if you change the string as long as it isn't longer than the original (that's where you get into troubles and have to reverse engineer the code). If the new string is shorter you have to add appropriate padding of 0x00 bytes because many string manipulation functions rely on proper termination as you said. It doesn't matter either if the size is hardcoded because it will copy a properly terminated string (with more termination bytes than usual). Games may be buggy and handle text their own way but we are talking about homebrew here and on top of that just a hardcoded path.
I have not experienced a bug related to optimizations for new archs. And support for ARM7/9 used in the DS isn't going away any time soon. The *TDMI variants are commonly used in microcontrollers and long term support is a must in the embedded market. Whatever you are doing, you do it wrong if GCC doesn't spit out the right code. There are numerous options to get what you want. -march + -mtune usually tell GCC automatically to use the best settings for your CPU.
Last edited by ghjfdtg,
I think you should do a bit of research before comparing homebrew environment vs games environment. You'll be amazed. (hint: this is how hackers sometimes look for exploits, through open source code, which sometimes is the same or very similar in game environment, same as webkit exploits)
1)
https://launchpad.net/gcc-arm-embedded/+milestone/4.6-2012-q4-update
2)
https://e2e.ti.com/support/legacy_f...lignment-issues-after-upgrading-to-Linaro-4-7
3)
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1804004
(ARM target generates unaligned STRD instruction)
Albeit old that doesn't mean GCC can't incorrectly generate code. Of course I tested what I am saying. And of course some GCC builds for ARMv4t can cause ARM7 exceptions, don't even talk about the linker as that also causes misalignment or random issues.
If that happens to GCC devs, mere users of their environment can't really be more accurate than themselves. I trust them more since I can GDB debug some exceptions and reverse engineer things. And also by looking at binaries (+ symbols) and reading the assembly generated, I was able to track down the above issue (armv4T)
Last edited by Coto,
I guarantee you there is no way it will crash if there is proper padding. I know about common faults of handling strings and exploited one myself a good while ago.
That strd "bug" is not a bug. GCC is just assuming unaligned accessex are enabled in the case you linked. Some newer ARM archs let you change the behavior on unaligned access (in the linked case Cortex-M4). If this is not supported and alignment is required GCC will not generate code like that. It's the reason -march and -mtune exist.
That strd "bug" is not a bug. GCC is just assuming unaligned accessex are enabled in the case you linked. Some newer ARM archs let you change the behavior on unaligned access (in the linked case Cortex-M4). If this is not supported and alignment is required GCC will not generate code like that. It's the reason -march and -mtune exist.
Welcome to the real (hackers) world. Aren't hackers all fight for freedom of choices?
what make leseratte started all these?
Because he want to add Wiimmfi update in the automatic Wiimmfi patcher in USB-Loader GX but he can't compile ULGX. You may blame Cyan not updating to lastest toolchain but Cyan already don't have enough time to fix bugs or implement new features in his long wish list and had a hard time figuring how to update and work with the latest toolchain. Gregwolf was (still?) trying to fork and update ULGX to the lastest toolchain for months (not seconds!!). Maybe he should go after the devkitpro team for help from the beginning... Remember, both Cyan and Greywolf are not the original ULGX developer. There are still a lot of unknown areas in the codes.
Thanks to the old toolchain leseratte found and the project is now completed. Otherwise he will have to wait (indefinitely) for Cyan to update to latest toolchain and then he can start the project (if he still had the drive) - which in real life terms means - next to never.
Maybe we should all stop using/improving ULGX because it doesn't confirm to "current coding standards?"
Are there any Wii homebrews still in development, and conform to the latest toolchain requirements? Maybe it is much simpler to let the Wii scene RIP??
Last edited by tswntk,
- Joined
- Nov 28, 2013
- Messages
- 2,921
- Trophies
- 3
- Age
- 21
- Location
- Virtual Earth
- Website
- lillie2523.carrd.co
- XP
- 4,790
- Country
What I meant is that had Winter not deleted the old binaries or made the newer ones backwards compatible, this archive would not be needed in the first place.
- Joined
- Dec 7, 2006
- Messages
- 771
- Trophies
- 1
- Age
- 32
- Location
- Netherlands
- Website
- www.jessesander.nl
- XP
- 2,450
- Country
It was just an example. But for a 'small' change I'd still rather use a snapshot of the toolchain that was used when the source was compiled instead of running in possible unknown behaviour after solving compiling problems with updated code.
For projects I want to polish and share with the public however.. I will use the latest toolchain of course. I don't really see the harm in an archive just for this purpose.
Similar threads
-
- Article
-
Xdqwerty
what are you looking at? -
Sonic Angel Knight
-
BakerMan
The snack that smiles back, Ballsack! -
AncientBoi
-
Sicklyboy
-
-
-
-
-
-
@
SylverReZ:
@Psionic Roshambo, The Doom NES cartridges, a few batches were made. One was given to AVGN as seen in his Doom video.+1 -
-
@
Sicklyboy:
I finally modeled and 3d printed the new HDD cages I need in order to build my 2nd NAS. Original ones don't fit the mounting holes on the hdds I'm using. Been sitting on this project for over 2 years smfh
-
-
@
Sicklyboy:
I'm finally gonna get this NAS racked and powered on tonight, install truenas core, and burn the disks in with badblocks
-
@
Sicklyboy:
Also another 70TB going in the front mount drive bays of this server. 182tb raw, going to probably use a zfs RAID-Z3 for 3 parity disks, so 140TB usable
-
@
Sicklyboy:
I could claw back 14tb by only doing 2 parity disks but I feel like with 13 disks in the RAID I'd be kind of pushing my luck on rebuild time if I encounter a disk failure
-
-
-
-
-
-
-
-
-
-
-
-
-
