Thanks for this thread, it’s much needed as anything relating to using MSVS products on Windows is always an endless nightmare of troubleshooting and hacks — one would expect that Visual Studio (one of the best MS products after XBox) should install flawlessly under Windows, but that’s not the case.
I’m stuck with the Win 10 SDK, which I need for languages like Rust and Nim, so uninstalling it is not an option. My hope is to find a way to compile the IDE under Win 10 SDK (although it would be much better if the precompiled binaries of those couple of C components would be added to the repository, after all users are interested in the PB code of the IDE, not the C part).
A few comments on a couple of things that came up in this thread.
Paths Containing SpacesMake and other Linux tools will break when presented with paths containing spaces, which are the norm when it comes to installed apps on Windows.
The quick workaround to this is using the short paths from the DOS era, which you can obtain via the
/X option in the
DIR command.
Code:
C:\>DIR /X prog*
11/12/2019 04:21 <DIR> PROGRA~1 Program Files
10/11/2019 14:05 <DIR> PROGRA~2 Program Files (x86)
From the above we learn that instead of
Program Files we can use
PROGRA~1, and instead of
Program Files (x86) we can use
PROGRA~2. Since short paths never contain spaces we are able to provide Unix tools with valid paths.
About UnxUtilsToday I’ve looked into UnxUtils, as I always do before even considering installing something on my PC, and what I discovered didn’t please me at all. See my recent Issue on this:
The UnxUtils are extremely outdated, having been created between 1999 and 2003, which means they were targeting Windows 95 or XP (most were compiled using MS VC 5.0). These tools represent a huge security hole for any PC, and in any case the tools of that package are really lagging behind their Unix counterparts. From what I read on SourceForge comments, many don’t even work as expected, other are simply broken.
The point is that we surely don’t need all 123 of the UnxUtils tools to build the IDE, and most of those that we do need are going to be available either on Win 10 natively, or in the Bash that comes with Git installation. So, probably we’d be missing only the Make tools for our needs — which you’ll already have if you’ve installed MinGW for any reasons, except that it’s renamed as
mingw32-make.exe, but you only need a symlink to make it work.
Anyhow, finding updated versions of the GNU tools ported to Windows is not a problem, there are many versions in the wild to choose from — but UnxUtils? no thanks.
(the UnxUtils package doesn’t even contain a copy of the GPL license — which says it all on the commitment of its author toward the GNU philosophy)
Using the MSVC Build Tools InsteadWhy install the whole Visual Studio package (which is huge) when all we need is available in the Build Tools distributions? For recent versions of MSVS Microsoft always provides a separate Build Tools distribution:
You can install multiple Build Tools on the same machine without conflicts, because to use them you must run a batch file that sets all the env vars to make its tools accessible, so they are effectively isolated tools.
Of course, you still need to install the correct SDK for the Build Tools, and as far as I know you can’t install multiple SKDs on the same machine.
DirectX SDK: Needed?As @kenmo pointed out, are these really needed?
- Microsoft DirectX 9.0 SDK (December 2004)
- Microsoft DirectX SDK (August 2009)
I can’t see them in the Win 10 SDK, so I was hoping that they are not strictly necessary for building the IDE. (does the IDE use DirectX anywhere?)
The RTM .Net Framework 4 ErrorFailure to install Win 7 SDKs due to the
RTM .Net Framework 4 error is a known issue that always pops up on the Internet. The registry hack is a
bad solution, and I stronly advice against it! While searching this error I’ve also found the registry hack solution proposed many times, but it’s really a quick-and-dirty solution that became popular because it seems to solve the problem at root. I’ve found many contradicting opinions and solution regarding this problem, but ultimately I did manage to find some good solutions too.
The truth is that it’s a rather simple problem which requires a clean solution.
The problem is that the SDK installer find a more recent version on the machine (
.NET Framework 4.5, which is bundled with Windows), so the SDK installer abort with error. The solution is uninstalling the
.NET Framework 4.5 and let the SDK install the older (deprecated) version — once you’ve installed the SDK and you update it, version 4.5 is reinstalled automatically.
For a good tutorial on how to install the Win 7.1 SDK without crazy hacks that expose your machine to a Blue-Screen-of-Death time-bomb countdown, see this article:
The Batch Helper@ChrisR, that of creating a batch script to help with the installation is a good idea. I was looking at your script and noticed that it requires privileges elevation to run as Admin.
What worries me is that besides installing and uninstalling package it also unpacks archives, which means that those files and folder will be owned by Admin, and may behave unexpectedly under normal privileges conditions.
Wouldn’t it be better to only launch sub shells with Admin permission when strictly required, and keep the base script running normally?
Personally, I was thinking of writing a Bash script, on the assumption that end user will have installed Git and surely have a Bash. You get all the Windows tools plus the Bash tools, and you can write more flexible scripts.
But maybe the best solution is creating a PureBasic program that can handle all the various compilation settings and either generate a customized build script or directly handle all the build process, including invoking Make. After all, this is a PB project, so it would be the easiest solution for end user, covering all three platforms.