The installation is not being completed on Windows 10

[LOuroboros]

Hi. Say, I can't install devkitPro's GBA Development Package which contains devkitARM on my Windows 10 machine, and I'm not really sure why. Has anyone come across any of these errors before?

The only reason I can think of for this not to work, is that it may rely on a Windows Service I may have disabled by accident, which makes me wonder, is there a list of the Windows Services devkitPro makes use of somewhere?

For reference, I tried to check the solution provided by tigrouind in the issue he opened more than 2 years ago in this repository, but even though I already made sure to check SSL 3.0 which is the only SSL related option I have in the Internet Properties window, it still doesn't work.

[WinterMute]

Looks like the msys2 bundle isn't being extracted correctly. Can you show a listing of the <installdrive>:\devkitPro\msys2\bin folder?

At this point it's probably best to uninstall the tools & start over. Also delete msys-2.10.0.7z if it exists and it might be worth disabling any antivirus software you have running temporarily while the installer does its thing.

If that doesn't work then try using upstream msys2 & following the customising existing pacman install instructions instead.

[LOuroboros]

Can you show a listing of the <installdrive>:\devkitPro\msys2\bin folder?

I actually can't because there isn't one.

At this point it's probably best to uninstall the tools & start over. Also delete msys-2.10.0.7z if it exists and it might be worth disabling any antivirus software you have running temporarily while the installer does its thing.

I already tried to reinstall a couple of times, but I always get the same result. I don't use an antivirus software, so that shouldn't be a problem either.

If that doesn't work then try using upstream msys2 & following the customising existing pacman install instructions instead.

Hm... I'll give that a shot, I guess. I'm pretty sure this is a fuckup on my end though. I had to reinstall Windows 10 a few days ago for reasons, and I may have disabled a service relevant to devkitPro's functioning by accident, which is why I asked if there was a list somewhere, of the Windows Services it may use to do its operations.

Thank you for replying!

[WinterMute]

Sorry It's <installdrive>:\devkitPro\msys2\usr\bin I meant. I forget msys2 moved things.

Windows 10 has defender built in. Generally I recommend people exclude the devkitPro folder from scanning since it slows down compiling.

My first thought here is really that the msys2 bundle has got corrupted in some way or that an antivirus is either removing gpg or preventing it from running. Msys2 upstream may know better if your disabled service theory is more likely.

[LOuroboros]

Sorry It's :\devkitPro\msys2\usr\bin I meant. I forget msys2 moved things.

There's a lot of files in there so I recorded a quick video showing the full content. Here you go.

https://streamable.com/qfwn48

Windows 10 has defender built in. Generally I recommend people exclude the devkitPro folder from scanning since it slows down compiling.

I have it fully disabled.

My first thought here is really that the msys2 bundle has got corrupted in some way or that an antivirus is either removing gpg or preventing it from running. Msys2 upstream may know better if your disabled service theory is more likely.

Alright, then I have no choice but to try it. I'll edit this comment with the results.

EDIT: I would really prefer to get the Windows installer working though, since the piece of code I intend to use is a bit strict on its ways, so I'm still opened to suggestions to fix the errors above. If there's any other information I can provide, let me know.

EDIT2: I was able to get around my troubles by simply using an unofficial and portable build of devkitARM. The main shackle I was burdened with was the requirement of devkitARM r45 specifically which is not being offered by you guys any longer, I was going to have to use it in any case even if I was able to install devkitPro via the Windows installer successfully.

At the same time, my biggest fear was that I wouldn't be able to use such a specific version of devkitARM with the upstream version of MSys2.

But yeah, in the end, I just relied on an unofficial build of devkitARM r45, adjusted my Windows Environment Variables a little and managed to pull through.

Thank you very much for your help, @WinterMute! Should I close the issue since it was solved?

[WinterMute]

You should not under any circumstances rely on old builds of devkitARM. If you have something that pretends to need a version that old then you should ask for help getting it updated for use with newer tools, depending on what it is. We have no idea what unofficial binaries contain and you should not use them. There is also a lot more to our tools than some random version of one particular toolchain which can and will cause weird issues with code you attempt to build.

The windows installer only installs our lightly customised msys2 bundle and does some setup work. There's no real difference between that and what you end up with by manually customising upstream msys2.

Your biggest fear should be that the project you're compiling cannot be built with current tools. Relying on old versions that cannot be verified as genuine leaves you and your users vulnerable to malware as well as forcing others to be dependent on things that can't and won't be supported which vastly limits the ability to find appropriate assistance when things go wrong.

[LOuroboros]

You should not under any circumstances rely on old builds of devkitARM. If you have something that pretends to need a version that old then you should ask for help getting it updated for use with newer tools, depending on what it is. We have no idea what unofficial binaries contain and you should not use them. There is also a lot more to our tools than some random version of one particular toolchain which can and will cause weird issues with code you attempt to build.

I have not developed the project that relies on devkitARM r45 and I am trying to use. It's a project that is no longer being mantained, and one that does not build correctly under devkitARM r47 and newer versions, and while it builds under r46, the project generated is seemingly unstable and prone to crash as noted by one of the project's mantainers.

Your biggest fear should be that the project you're compiling cannot be built with current tools. Relying on old versions that cannot be verified as genuine leaves you and your users vulnerable to malware as well as forcing others to be dependent on things that can't and won't be supported which vastly limits the ability to find appropriate assistance when things go wrong.

I trust the person who provided the unofficial build of devkitARM r45 that I am using, because he seems to be genuine in his intention of preserving precompiled versions of toolchains, versions that you guys decided to kill off the face of the internet disregarding or maybe just not caring at all about old unmantained projects that, for good or bad, can be the only or the best choice available to do a certain thing, and still rely on such previous versions of specific tools.

I have no basis to declare that the unofficial build of devkitARM r45 that I am using is not a virus, but I don't think is. It doesn't look like it is, it doesn't seem to be doing anything shady to my computer, and the computer itself does not work any differently with its files stored on my PC either.

As I am not a programmer, but mostly a tester of sorts and a user, I cannot update the project myself, and I don't really have a reason to even if I could.

I want to believe that I'm pretty good at avoiding shady websites. So if a website looks genuine, the person providing the tool is seemingly trustworthy as a credible source, and the files seem legit, I don't see a reason to doubt them.

I would like to take the chance and voice my own opinion in that precompiled older versions of devkitARM should be shared officially just as they were on SourceForge a few years ago, perhaps with a note clarifying that they're no longer supported, just as a fallback for projects like the one I had to use, projects that are no longer being mantained, that there's no better alternative to and have to rely on such old versions of tools. I never understood why were those precompiled versions removed, but I surely can't agree with the decision. I feel like that's not going to happen though, so yeah.

As far as I am concerned, the issue has been solved.

[WinterMute]

I have not developed the project that relies on devkitARM r45 and I am trying to use. It's a project that is no longer being mantained, and one that does not build correctly under devkitARM r47 and newer versions, and while it builds under r46, the project generated is seemingly unstable and prone to crash as noted by one of the project's mantainers.

I understand this. The project should however be updated to use latest tools. Insisting that people use old tools instead of fixing the code has repercussions that cause problems far beyond a single project.

I trust the person who provided the unofficial build of devkitARM r45 that I am using, because he seems to be genuine in his intention of preserving precompiled versions of toolchains, versions that you guys decided to kill off the face of the internet disregarding or maybe just not caring at all about old unmantained projects that, for good or bad, can be the only or the best choice available to do a certain thing, and still rely on such previous versions of specific tools.

The person you refer to is misguided at best.

We're also not disregarding or not caring about old unmaiintained projects. We will absolutely provide assistance in bringing old projects up to date where possible.

As I am not a programmer, but mostly a tester of sorts and a user, I cannot update the project myself, and I don't really have a reason to even if I could.

This is the part that seems most difficult to get across. The reason to update the project is to help others avoid the pain that you face in using it. This is the whole point of open source - so that projects can continue to be maintained long after the original author has lost interest and moved on. Even if you don't have the skills to do that now, they're useful skills. Even if you have no interest in gaining those skills there are others around who do. There are other people around, most especially us, who are interested in making homebrew as accessible as possible which often does involve helping people to update old projects.

I want to believe that I'm pretty good at avoiding shady websites. So if a website looks genuine, the person providing the tool is seemingly trustworthy as a credible source, and the files seem legit, I don't see a reason to doubt them.

The fact that we no longer provide nor support the binaries in question should give you major pause for thought. The person you refer to is hosting illegal copies of many binaries and bypassing bans in order to rehost binaries in a way that can and will prevent users from building working code. Your trust is misplaced.

I would like to take the chance and voice my own opinion in that precompiled older versions of devkitARM should be shared officially just as they were on SourceForge a few years ago, perhaps with a note clarifying that they're no longer supported, just as a fallback for projects like the one I had to use, projects that are no longer being mantained, that there's no better alternative to and have to rely on such old versions of tools.

The better alternative is to talk to us and either try to get the projects updated to work with modern tools or find better alternatives which suit your needs. Using old tools and trusting people who provide them against our wishes undermines the work we do that makes homebrew possible and accessible.

I understand that it's frustrating when old projects don't build and other people have long since moved on but a little effort now can and will save a lot of pain and frustration later.

As @asiekierka has explained above it's not as simple as just chucking an old devkitARM in your path and calling it good. There are dependencies between all the components that can and will cause issues if you mix and match them inappropriately.

I never understood why were those precompiled versions removed, but I surely can't agree with the decision. I feel like that's not going to happen though, so yeah.

Using and promoting old binaries is rather selfish and short sighted. It actively prevents projects from being maintained and brought up to date and encourages others to vandalise a carefully curated set of tools and libraries causing them to malfunction in various subtle and not so subtle ways. This often ends up with support requests from people who don't understand why none of our example code works when they try making their own homebrew instead of just playing with someone else's code. We cannot support old binaries, we will not provide them and others should think carefully about what they're doing and the consequences of their actions.

[LOuroboros]

@asiekierka asiekierka

Not caring at all? I think that's an overly harsh accusation - many of us have worked on updating unmaintained projects ourselves. Many of us are extremely well aware they exist, but feel that it would be a net benefit to the community to update them properly over simply disregarding the problems older toolchain versions bring and moving along as-is.

It's not an accusation of any kind. It's me taking a very wild guess to understand a situation that I was not involved with at all and that I have no proper information about. An outsider's perspective, I guess.

I apologize right now if I sounded harsh enough for my words to be considered a direct attack or a serious offense. I did not mean them to come across like that really.

I never understood why were those precompiled versions removed, but I surely can't agree with the decision.

Let me try to give some examples of reasons:

* Many problems you may run into were already fixed in newer versions of the toolchain and its libraries.

* These are not just developer-facing problems. There are very clear issues with using old versions of libraries - for instance, an old version of libnds will not support the DSi's SD card correctly; an old version of libogc will not support Wii controlles with MotionPlus integated. I've used pieces of DS homebrew from 2008 which were not recompiled since and caused issues going as far as FAT corruption - I'd love to fix them, but often I don't have any route to as they were closed-source!

* Following from the previous point, mix-and-matching library and toolchain versions can cause problems and instabilities of its own (changes in newlib may, for example, influence bridge code in libfat).

Does this help you see the reason?

No, it doesn't. What you're describing here is the benefit of using newer versions of a determined toolchain. That doesn't really explain to me why were the old versions removed completely, again, as if not caring at all about projects that for X or Y reason may be stuck in their place using one of those old versions of this determined toolchain. Projects that have no one to look after them. Projects that people may still need to use.

I still stand by my opinion that hosting them with a gigantic warning stating that they're officially unsupported and if a person must use them, they must do so at their own risk is a much more better solution.

@WinterMute

I understand this. The project should however be updated to use latest tools. Insisting that people use old tools instead of fixing the code has repercussions that cause problems far beyond a single project.

I'm not seeing those repercussions myself, like, I don't comprehend why directing users to a process that works (or well, worked since the specific version of devkitARM being used is not officially distributed any longer) would have any repercussions on anything at all, but okay.

Regardless of my opinion on the matter, which is that certainly, the project should be updated, nothing will change because no one is willing to work on it, in this particular case.

The person you refer to is misguided at best.

We're also not disregarding or not caring about old unmaiintained projects. We will absolutely provide assistance in bringing old projects up to date where possible.

where possible.

Yeah, that's kind of the problem. It may as well not be possible. Or maybe it is. To be honest, I couldn't tell because I myself am not a developer.

I don't think linking it here would have any negative repercussions, so I could link it here if you were willing to look at it in order to draw some conclusions, if it's necessary.

This is the part that seems most difficult to get across. The reason to update the project is to help others avoid the pain that you face in using it.

Yeah, you're right and I know that. Projects should always be constantly mantained and being kept in shape using the latest version of whatever tools it needs to use, and I am aware of that fact for whatever that's worth. I understand that bugfixes are implemented, that code is optimized and features can be modified to function more easily then before. I understand there's multiple advantages in updating a set of tools and it's a practice that I would probably follow if I was a programmer.

The fact that we no longer provide nor support the binaries in question should give you major pause for thought. The person you refer to is hosting illegal copies of many binaries and bypassing bans in order to rehost binaries in a way that can and will prevent users from building working code. Your trust is misplaced.

I cannot argue with that, but at the end of the day, nothing really changes. I still need to rely on older versions of devkitARM that are no longer being offered officially in order to build certain projects that make use of them, forcing me to take an alternative path. This person's FTP page containing older builds, which again, do not seem to contain any malicious file at all, is this alternative path.

I took a huge risk security wise, one that I would have had to deal with which is something I am fully aware of and also fully accept.

As @asiekierka has explained above it's not as simple as just chucking an old devkitARM in your path and calling it good. There are dependencies between all the components that can and will cause issues if you mix and match them inappropriately.

Just so we're clear here, the project that I had to build made explicit use of devkitARM r45, so I knew which version I needed to use from the get go. I mentioned how one of its former mantainers noted that building it under devkitARM r46 could lead to unstable results, yes? I know that because the project's README contains instructions on how to build it.

So yeah, there wasn't much room for failure. The biggest thing that could have caused a trouble here is if, again, the custom build that I had to use was not of devkitARM r45.

It actively prevents projects from being maintained and brought up to date

I don't see how. Hosting older/legacy versions of tools wouldn't discourage someone willing to work on a project to update it and upgrade it to make it better whenever it's possible. ... Right? Is that not the case?

and encourages others to vandalise a carefully curated set of tools and libraries causing them to malfunction in various subtle and not so subtle ways.

I'm not sure I can see the relevancy of that statement here. I mean, if someone wanted to vandalize these tools, they would do it whether they had to use an old version or the latest one.

This often ends up with support requests from people who don't understand why none of our example code works when they try making their own homebrew instead of just playing with someone else's code. We cannot support old binaries, we will not provide them and others should think carefully about what they're doing and the consequences of their actions.

I could understand if the distribution of older versions was cut off as a way to reduce the chance of scenarios where newcomers use old tools that are no longer being supported and then ask for help in official places when something doesn't go as they intended to from happening. I still believe that old binaries should be provided with a gigantic note stating they're absolutely unsupported and if they're used it should be at the user's own risk or discretion, with bold font and red color even.

But yeah, these are just my personal thoughts on this whole thing. My opinion, naturally subjective.

I feel the need to clarify that I didn't mean to stir up trouble in this place, and I was not trying to be rude when I took my wild guesses on what is again a matter I am not involved in at all either, so I apologize if I was rude. I just didn't mean to. Hell, I didn't even mean for this to have gone any further than "The issue has been solved, should I close this now?".

[asiekierka]

Hosting older/legacy versions of tools wouldn't discourage someone willing to work on a project to update it and upgrade it to make it better whenever it's possible. ... Right? Is that not the case?

In my experience, that has happened before actually! I've seen a case of it in homebrew, but also in other scenes (f.e. Minecraft modding, where updates are often significantly more rough and time-consuming). However, there's other concerns to be had, too: as many third-party tutorials and guides are written with such legacy versions in mind, as well as lots of codebases existing only available for those old versions, it may appear easier to just use an older version to write new code as well.

No, it doesn't. What you're describing here is the benefit of using newer versions of a determined toolchain.

If "not having bugs" and "supporting hardware better" is a benefit of using newer versions, "having bugs" and "not supporting hardware well" is a drawback of using older versions - both clearly harm the experience of the developer and of the end user. It works both ways.

That doesn't really explain to me why were the old versions removed completely, again, as if not caring at all about projects that for X or Y reason may be stuck in their place using one of those old versions of this determined toolchain. Projects that have no one to look after them. Projects that people may still need to use.

Because the toolchain's view, at least as I understand it, is to prioritize the well-being of the homebrew ecosystem as a whole - and that requires, among other things, encouraging good standards and discouraging bad practices both. I am painfully aware that this will leave some projects in the dust (I've updated some myself, after all, and am aware of some which have not managed to update yet despite developer efforts), but I think it's a case where the benefit of the many may outweigh the needs of the few

I still believe that old binaries should be provided with a gigantic note stating they're absolutely unsupported and if they're used it should be at the user's own risk or discretion, with bold font and red color even.

In practice, I think many people treat such warnings like they treat EULAs - with not enough attention.

[WinterMute]

That doesn't really explain to me why were the old versions removed completely, again, as if not caring at all about projects that for X or Y reason may be stuck in their place using one of those old versions of this determined toolchain. Projects that have no one to look after them. Projects that people may still need to use.

Providing binaries obliges us to provide support that we're no longer willing or able to provide.

If people still need to use a project then someone can be found to bring it up to date with current tools and libraries. This is the primary benefit of open source.

I understand this. The project should however be updated to use latest tools. Insisting that people use old tools instead of fixing the code has repercussions that cause problems far beyond a single project.

I'm not seeing those repercussions myself, like, I don't comprehend why directing users to a process that works (or well, worked since the specific version of devkitARM being used is not officially distributed any longer) would have any repercussions on anything at all, but okay.

You're the victim of those repercussions now. You can't build a project without recourse to unverifiable and unsupported binaries. Others that follow behind you will also face that situation. Some of them will want to make their own homebrew & discover that the modifications they made to the tools in order to compile this project prevent them from building working code in their own projects.

We've assisted probably 1000s of would be developers fix their ability to make homebrew after they destroyed a carefully curated set of tools and libraries by following some guide to building old projects. A guide that wasn't necessary. Others have sent me hate mail and given up on homebrew forever - precisely because they couldn't build something that, in a lot of cases, simply needed a few warnings fixed or a minor tweak to a Makefile.

We've seen and assisted with countless homebrew projects over the time we've provided and maintained these tools. We see more of the repercussions than most individual homebrewers or users of homebrew projects are ever likely to see.

Regardless of my opinion on the matter, which is that certainly, the project should be updated, nothing will change because no one is willing to work on it, in this particular case.

The thing is ... we're perfectly willing to assist in bringing old projects up to date. Personally I'd also like to figure out what the issue is that prevented you from using the windows installer in the first place.

We're also not disregarding or not caring about old unmaiintained projects. We will absolutely provide assistance in bringing old projects up to date where possible.

where possible.

Yeah, that's kind of the problem. It may as well not be possible. Or maybe it is. To be honest, I couldn't tell because I myself am not a developer.

We'll never know unless we try.

I don't think linking it here would have any negative repercussions, so I could link it here if you were willing to look at it in order to draw some conclusions, if it's necessary.

We prefer to provide more general support (like building and updating projects) on the forums at https://devkitpro.org/viewforum.php?f=37 rather than the issue trackers.

[WinterMute]

Getting back to the original issue though ...

It seems like you may have broken the Windows Null Service somehow. You can check this by running echo hello > nul from a cmd shell which I guess should give you an error message.

If that's the case then resetting the device defaults may work - see http://revertservice.com/10/null/ for details. If that allows the echo command above to work without errors then hopefully removing the broken toolchain install (delete the devkitPro folder, ensuring it gets completely removed) & running the updater again should hopefully get you working, up to date tools.

[LOuroboros]

Providing binaries obliges us to provide support that we're no longer willing or able to provide.

It really does not. You wouldn't be expected to support a tool posted right under a "This is no longer being supported. You shouldn't be using this, but if you do, good luck and have fun. You're alone." note, but okay.

If people still need to use a project then someone can be found to bring it up to date with current tools and libraries. This is the primary benefit of open source.

Yes and no, in my opinion. Is it possible? Yes. Is it likely to happen? Probably no.

You're the victim of those repercussions now. You can't build a project without recourse to unverifiable and unsupported binaries.

Because there isn't another option for this particular task, and because you decided to kill off every legitimate way of getting the required binaries when it was not really necessary.

Others that follow behind you will also face that situation. Some of them will want to make their own homebrew & discover that the modifications they made to the tools in order to compile this project prevent them from building working code in their own projects.

Saying that it "will" happen is a bit too much because this project's main target is users just like me who don't write code and only want an easy way to implement a bunch of features on a certain game without having to worry about anything else.

It can happen, but from my point of view it is very highly unlikely to.

The thing is ... we're perfectly willing to assist in bringing old projects up to date. Personally I'd also like to figure out what the issue is that prevented you from using the windows installer in the first place.

So should I just go ahead and link it?

We prefer to provide more general support (like building and updating projects) on the forums at https://devkitpro.org/viewforum.php?f=37 rather than the issue trackers.

Then I should make an account in the devkitpro forums and bring up the matter? To provide a clearer view, the project is an injection of C code for a Game Boy Advance game whose ROM file must be provided by the user.

I'm not entirely sure if it's something that would be welcomed there or not or if anything of value is going to come out of this, hence why I ask for confirmation before doing anything.

It seems like you may have broken the Windows Null Service somehow.

That was definitely the cause of the problem. I booted it up and the devkitPro installer did its thing normally. Thank you!

[WinterMute]

Providing binaries obliges us to provide support that we're no longer willing or able to provide.

It really does not. You wouldn't be expected to support a tool posted right under a "This is no longer being supported. You shouldn't be using this, but if you do, good luck and have fun. You're alone." note, but okay.

We can't do that under the terms of the GPL. We have certain obligations to support binaries that we provide for a minimum of 3 years.

We prefer to provide more general support (like building and updating projects) on the forums at https://devkitpro.org/viewforum.php?f=37 rather than the issue trackers.

Then I should make an account in the devkitpro forums and bring up the matter? To provide a clearer view, the project is an injection of C code for a Game Boy Advance game whose ROM file must be provided by the user.

I'm not entirely sure if it's something that would be welcomed there or not or if anything of value is going to come out of this, hence why I ask for confirmation before doing anything.

Go for it. Like I said we have no idea what can be done unless we try. The tools aren't really designed for ROM hacking and we don't support piracy but that doesn't mean we won't help people doing their best to stay within the boundaries of the law.

It seems like you may have broken the Windows Null Service somehow.

That was definitely the cause of the problem. I booted it up and the devkitPro installer did its thing normally. Thank you!

Awesome. We can close this now we actually solved the issue rather than just sidestepping it :) Thanks for persevering.