Universal C Runtime Windows 7 Download
Lauren Redder
Non so se hai risolto o meno, ovviamente consiglaire di installare Windows 10 SDK una soluzione stupida, come uccidere una mosca col bazooka. Io ho aperto due ticket con il supporto tecnico (per CREO e per Mathcad) e in nessuno dei due sono ancora riusciti ad arrivare a nulla. Le soluzioni che mi hanno proposto, e che ti rigiro, sono:
A differenza del tuo caso io ho Windows 7, dallo screenshot mi sembra che tu abbia windows 10 quindi non hai bisogno dell'hotfix ma del runtime vero e proprio, che hai gi provato a installare. Devo dire che sono infuriato con PTC, pago un mantineance fee non indifferente e non posso fare gli aggiornamenti. Ridicolo.
Sperando che correggano il problema. Per ora il supporto tecnico non ha messo mai in discussione il funzionamento del loro installer, stanno lavorando per stabilire quali aggiornamenti sono essenziali all'installazione perch "non tutti gli utenti fanno tutti gli aggiornamenti di windows". Peccato che IO li ho fatti tutti gli aggiornamenti, e comunque non funziona. C' qualcosa d'altro che causa il malfunzionamento.
Ahaha not so fast ;D It's a week I'm installing all the updates and trying all the workarounds PTC tech support is providing, but NOTHING works. I also installed Win10 SDK and still it doesn't work. It seems to me that something is not working as expected in the install software when not run under Win10, but PTC has no clue what's going on and there's no log I can check to see what's missing.
Now tech support is filing this as SPR trying "to define the minimum patches required for Creo 4.0 installation", but again, this is not the issue: my system has all the updates and Microsoft update says it's all right, so either there's something not working in Windows Update or there's something not working in PTC installer. I don't see how having a list of required updates (which I already have since I have ALL updates) could change this.
Only thing I can say is that the technical support is working on the issue, they already provided some experimental build which allowed me to both install and run Creo 4.0 M010 correctly, but it's still unofficial and preliminary. Trying to figure out what is not working seems a bit tricky but the guys are definitely on the good track.
Microsoft recommends installing the Universal Runtime by either Windows Update or the Visual C++ Redistributable when possible. After that further updates to it are handled automatically by the standard Windows Update mechanism.
The only time I deployed an app without the DLLs but with the installer of the runtime, up to 10% of the cases, the installation FAILED, the solutions ranged from windows updates so outdated that taked HOURS or even days to install service packs and fixes (the prerequisites) before installing the runtime, to some cases where windows update was not even working so the only option was to reilstal windows.
But sure, your mileage can vary depending ow what kind of users you target, the minimum os version, the number of users and how much time you are prepared to waste on client support to update the windows of the final users.
There are MILLIONS of windows 7 users. You can either trow a tantrum and tell them their daily work horse is useless and have to migrate to a new OS, or you can ship some DLLs and have them as customers.
The microsoft-metro tag is really bad. There was never a thing called "Microsoft Metro" and I've never heard anyone using such term. The correct term was "Metro Design Language" and so it was originally about the design language that evolved from Windows Media Center and especially Zune and was later adopted to Windows Phone 7, Windows 8 and eventually all Microsoft products and for reasons I don't want to speculate about here it was renamed as the "Microsoft Design Language" and so it was not used much if at all at Stack Overflow unless perhaps in cases when people wanted to write programs imitating the design aspects. Before 2012 it was only that - a design language and life was good.
When Microsoft announced Windows 8 in 2012 - they announced a new part of the shell and kind of apps for Windows that they called "Metro Style Apps". That was a horrible idea #1 since they had no way to enforce the design of the apps people could publish to the store other than by the default design of the controls they made available. Also supposedly because they were sued by the big box retailer Metro AG about the name which coincided with Microsoft stopping all uses of the term and so the confusion has grown even further. For a while people kept asking Microsoft what names to use instead and Modern UI, immersive UI or immersive apps were thrown as names of the new touch-first area of Windows. Also a codename "Jupiter" leaked which was temporarily either the internal name for the full-screen window hosting the new type of apps or maybe the XAML part of the framework (the UI of the apps can be written either in winrt-xaml, winjs or directx). Finally Microsoft started to use the name "Windows Store Apps" for the new type of apps and "Microsoft Design Language" for the design language.
By this time many people already started associating the term Metro with this new type of apps though and so the many of them still confused about the names started tagging their questions as metro. The problem though was that the tag was already reserved by the Java web stack technology, so to separate these - a new tag microsoft-metro was created and extensive effort to keep retagging questions tagged as metro to the new ones was started. Later the Java tag was smartly renamed to java-metro-framework. The problem though is - there is no such thing as "Microsoft Metro"!
The name of the entirely new development framework for creating these "Windows Store Apps" is and always was "Windows Runtime" or "WinRT" for short, but at some point Microsoft had another horrible naming idea and called the version of Windows 8 running on ARM tablets - "Windows RT" - perhaps to maximize confusion.
With all these terms being used at some points - you now have people using all of them on Stack Overflow, but in virtually all cases these questions are about the same area - building Windows Store Apps, which you actually use Windows Runtime to do. There are following numbers of questions in these categories now:
As a longtime Windows Store Apps developer using Windows Runtime and the Stack Overflow top answerer in the Windows Runtime category - this is my take on the matters. Note that while I currently work for Microsoft building apps for Windows Store - this is only my opinion as a developer and a Stack Overflow user and not the official statement of Microsoft as a whole or any of its product groups', teams' etc.
Your claim is that Windows RT and WinRT (aka Windows Runtime) are completely different, and based on your employment claims in your profile, you would be in a position to know (and some quick googling supports this as well). However, the names invite significant confusion because not everyone will pay attention to the differences.
There are questions under windows-rt that seem to be about windows-runtime, plus there are a number of questions with the tags microsoft-metro and modern-ui, not to mentioned the windows-store-apps questions, which seems to have a significant overlap.
I completely agree that the tags as they stand now are a problem, but I'm not sure the proposed synonyms are the right way to go. Tags need to be unambiguous and simple, otherwise you'll ends up with a lot of mistagged questions.
First is what used to be called "Metro", which was a reference to the gui language. The proper name of that seems to be microsoft-design-language. That tag current doesn't exist, so probably needs to get created, and any questions about the language should be sent there.
Thirdly, questions with the modern-ui tag that actually reference windows-runtime need to be retagged. The fact that there were brief references to this name when the Metro name was dropped probably have caused some users to think that this name references the metro-style apps.
Last is the confusion between WindowsRT and Windows Runtime. I'm not sure of the right answer here. Maybe clean up the current questions that are under the wrong tag, but it may be better to find a better way to limit the confusion in the future.
Ultimately, while I agree with the idea that something needs done here, I do not believe that a simple merge is the correct course of action. You'll be trading the problem of questions with an incorrect tag for a different set of questions with inappropriate tags. Unfortunately much of the effort is going to be manual labor to get as many of the questions with the wrong tag fixed before we consider synonyms or merging.
From Charles's comment, I see that the Windows-Runtime vs Windows-RT discussion has already taken place in Sorting out tagging for WinRT (Windows Runtime) and Windows RT (Windows on ARM) but no clear consensus seems to have been achieved
windows-rt I am on the fence on this, but lean towards keeping this as a separate tag to refer to Windows 8.x on Arm. I do think it is important to help distinguish between issues that happen only on the RT (Arm) version, and not the desktop (x86/ x64) version of Windows.
Microsoft themselves originated this confusion because of the confusing names surrounding the new APIs and programming environment.(Not trying to bash MS here, as I do enjoy using their products, and have a few scars from programming Metro/Runtime/whatever it's called today. But it was a bit confusing.)
My suggestion is to keep the Metro tag(s) separate, because most of the questions on it/them are probably old and not relevant to modern Windows 10 App Store programming anyway. IIRC, I have at least one question tagged Metro that is probably only relevant to Windows 8. The ecosystem has changed so much, that I think there is value in keeping at least the Metro name separate.
What about windows-runtime-api ? Since "runtime" (an implementation) and API (a specification) are normally mutually exclusive terms, this phrase hints that "runtime" is not just any runtime but a proper name here.
c80f0f1006