Cube IDE installation under win7-64 SP1

[PHolt.1]

This issue is all over the internet, and as usual with no good solutions.

One of the two files which Cube says is not present actually is in that directory. I am totally stuck, having spent a day on this and downloading all sorts of VC++ redistributable fixes. I am doing this on two machines, both running a win7-64 VMWARE VM. This is Cube 1.7 although I tried 1.6.1 also (which I have running ok on the base machine, but that machine has had years of updates...

Of course google searches take one to needing C++ redist update 2015 but that generates error 0x80240017 :)

[PHolt.1]

A little update: v1.4 installs OK.

So for win7-64 this looks like the only option. One can then update Cube using its own update feature, which currently offers 1.7 as the only option. However that fails too and you end up with the above error messages.

Edit: just discovered the likely cause of the problem: ST changed their system requirements post v1.4:

 

 although for some reason the online update to 1.6.1 worked ok on two win7-64 machines. But doesn't work on a 3rd win7-64 Enterprise SP1 running in a VMWARE VM.

[Pavel A.]

Well, as you probably know, Win7 is no longer a supported Windows version.

If you suspect that the cause of install failure is  VC++ 2015 redist update, or ucrt update - maybe there's is a medicine for that.

[PHolt.1]

Sure, but nobody is going to throw away a working win7 computer (with many apps installed and many weeks or months spent on data and configuration, etc) just because Micro$oft no longer "support" win7. The whole "security" issue is a complete non-issue unless using the machine for email (and especially if using M$ Outlook) and (to a lesser extent) www, which is why large chunks of industry still run test equipment on winXP.

One can find the VC++ 2015 and 2017 install packages but they fail, with error messages which google to thousands of hits ...

I suspect ST changed things after Cube 1.4 which is not that long ago.

[PHolt.1]

Cube 1.4 and 1.5 install and work. 1.6 does not.

It appears to be a dependency on which version of VC++ redists you have installed. Cube seems to need at least VC++ 2015, but this is extremely difficult to "just install"; you get obscure 8 digit hex error codes which google to huge numbers of ineffective solutions. The way to get VC++, up to 2019, was via regular M$ Windows updates, but they stopped a while ago.

[Pavel A.]

@PHolt.1​ Wait a little, we'll see people throwing away almost new machines that do not support Windows 11. Because Microsoft decided so.

Regarding the VC libraries, I can only advise to ask on the MS forums here or on SO.

IIRC, VC 2017 should work on Win7.

[PHolt.1]

"VC 2017 should work on Win7."

It does (this is from my win7-64 PC). You just can't install it from any of the install packs. It used to come on the M$ auto updates but they stopped (except for paying M$ support customers)

 

and sure enough Cube 1.6.1 runs fine on this PC. I just don't dare try to update to 1.7 in case it is broken on win7, and then I could get stuck.

[PHolt.1]

Cube 1.7.0 works fine under win7-64 SP1. Same compiler version as 1.6.1, too! More detail:

https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg3641416/#msg3641416

[Pavel A.]

> To run Cube in a VM you need to check the "shared STLINK" box otherwise you get verify errors on the STLINK code load.

This is interesting. Thanks.

[PHolt.1]

There is a variety of issues running Cube in a VM if you are using a debugger, due to USB device sharing issues. Well, a USB device cannot be shared :)

I successfully ran one Cube on the base machine, to one STLINK debugger, and another Cube in a VMWARE win7-64 VM to another STLINK debugger. The debuggers were STLINK 3 & STLINK 2 but that is probably not material. So this way you could run two (perhaps interacting) targets, two debuggers - potentially useful!

What is more messy is if you have a debugger connected and then start the VM. The VM will not pick up the USB device(s) because the base machine is holding them. You have to, as a minimum, unplug and replug the debugger USB cable and then the VM should pick up the debugger. And same if running the USB VCP for debug text. It isn't all that reliable, and I've had WMWARE do a BSOD which is otherwise very unusual.