Currently it at 6.1 it wanted to change to 10.0 because it want to upgrade to windows 10, but I’m scared because of windows crash. Can someone tell what happen what happens if we change the current version if it were expecting to crash my windows?
Related
I am working on a IddCx indirect Display Driver. I have run into a bug that I cant find any reason to blame my own code on. Every two seconds or so IddCxSwapChainReleaseAndAcquireBuffer takes over 100ms, up to 8000ms to complete. It normally takes below 16ms to complete (depends on your frame rate).
I even added timestamps to the IddCx Sample code from Microsoft. It still has this issue, so it cant be a fault with my own code. I have exhausted most of my debugging options.
Changing IddCx versions I am compiling with (1.4 to 1.8) by targeting the libs, the headers, and defining the macros (IDDCX_VERSION_MAJOR, IDDCX_VERSION_MINOR, IDDCX_MINIMUM_VERSION_REQUIRED). 1.9 btw doesnt seem to run well, IddCxDeviceInitConfig() fails with Invalid Parameter if I choose version 1.9.
Changing which UMDF version I am compiling with (2.25 to 2.33).
Changing the Windows SDK version I am using (10.0.19041.0, 10.0.20348.0, 10.0.22000.0, 10.0.22572.0).
Swapping my OS to the Insider Program preview version of win11 (currently 22000.588 co_release).
Things I think may be solutions that I need help on.
When I am running the Driver, within dxdiag, the display says its using WDDM version 1.3, while my other displays use WDDM version 3.0. WDDM 1.3 is old, so maybe this could be causing issues? How do I tell visual studio to compile my driver to compile with WDDM version 3.0? Does my driver need to WHQL Logo'd first?
IddCxGetVersion() returns with version 1801 or 1803 no matter what I change (SDK, IDDCx version, etc), which is from 2018! So what am I doing wrong here to get the OS to choose to use a newer version of IddCx? This may be related to the WDDM version being 1.3 instead of 3.0.
Swapping back to Windows 10. I originally swapped to Windows 11 because the WDK dev environment is completely unstable, with the samples sometimes not creating functional drivers, that fail to call into 'EVT_IDD_CX_ADAPTER_INIT_FINISHED', I have confirmed its being compiled incorrectly (sometimes) on windows 10, and the old dlls from earlier that day will still work, but the new dlls will not. So thats why I am staying with Windows 11, I also need to swap to Windows 11 anyways since we should be moving forwards, not backwards.
forgot to close this.
Realized the issue was that the monitor desktop simply wasnt updating. So the OS was just rendering the desktop less often, resulting in less frames being pushed to the swapchain for me to grab
I am a VisualC# programmer and an individual Unity3d game developer. I wanted to know if there was any problem if I upgraded from my windows 7 to windows 10, I wanted to know if there is any difference in performance. And one more thing.. From a programmers point of view is there any feature that I would not be able to get if I do not activate windows,meaning that I use deactivated Windows because I donot think why should I activate it.
New Windows versions introduce new API. E.g. GetSystemTimePreciseAsFileTime() was only added in Windows 8.
I'm attempting to install Java 8 JRE on Window 10, and it's failing. The purpose of this is so that I can install SQLWorkbenchJ on my Windows machine. This is my personal machine, and I have complete access privileges. Please let me know if I can provide any additional information to answer this question (e.g., logs).
I've downloaded Java 8 from Oracle, specifically the offline 64 bit version for windows. When I download it, it places the following icon on my desktop:
When I double click on this icon, the following image pops up:
After I click "Yes" and the popup box disappears, nothing happens. Windows continues operating as if nothing happened. The only trace of activity is in the task manager, which shows the following:
Does anyone have any suggestions on how to fix this? I'm at a loss for how to push the installation process forward.
Update: I was able to solve this issue by installing the x86 version (32 bit) instead. I'm not sure why the x64 version doesn't work on Windows 10, but I'd seen this solution subtly referred to elsewhere on the internet as a solution. Would be interesting if someone could figure out why the x64 version itself doesn't work.
We have two concerns here - 1. JRE 8u101 (64-bit) fails to install without an error message and 2. JRE 8u101 (64-bit) fails to install on Windows 10.
The first one seems similar to http://bugs.java.com/view_bug.do?bug_id=8148167 which is a known issue.
However, it would be appropriate to take a look at jusched and JavaDeploy log files to confirm the same.
The second concerns with 64-bit JRE installation in Windows
Microsoft Edge on Windows 10 is not supported a supported browser.
For Internet Explorer 11 on Windows 10, see:
Related bug ID: http://bugs.java.com/view_bug.do?bug_id=8162523
For a solution related to 64-bit installation, suggest you to follow the instructions from the comment in the above bug report.
Hope this helps.
This is known issue https://bugs.openjdk.java.net/browse/JDK-8148167 , this has already fixed in 8u111/8u112, early access builds are available here - https://jdk8.java.net/download.html, you can download and try to install the same. Do let us know your feedback?
I was having this issue as well and the 8u112 worked from this page
Thank you
I have a program that reports and/or detects the Windows OS version. It uses GetVersionEx, but Microsoft intentionally broke this API in Windows 8.1 and later to return incorrect version information. (Apparently proper version checking is just too hard for the masses to get right, but that's a rant for another topic.)
I know that I can add a manifest to work around this particular problem, but my question is about "future-proofing" the program.
If a future user runs the program on a newer OS than Windows 10, will GetVersionEx work correctly and report the "real" OS version, even if the program's manifest doesn't include that version's GUID?
Or am I doomed to continually add new GUIDs to the manifest every time a new OS version is released?
If a future user runs the program on a newer OS than Windows 10, will GetVersionEx work correctly and report the "real" OS version, even if the program's manifest doesn't include that version's GUID?
NO, and this is documented behavior:
With the release of Windows 8.1, the behavior of the GetVersionEx API has changed in the value it will return for the operating system version. The value returned by the GetVersionEx function now depends on how the application is manifested.
Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). Once an application is manifested for a given operating system version, GetVersionEx will always return the version that the application is manifested for in future releases. To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.
Or am I doomed to continually add new GUIDs to the manifest every time a new OS version is released?
Sadly, YES. The point of version manifestation is to explicitly report the OS version(s) that your app is known to be compatible with. Obviously you can't know ahead of time if it is compatible with future versions. So, whenever a new version is released, you test your app as needed, verify it working (and fix it if needed), and then update the manifest accordingly. Until then, Windows will down-grade itself to behave like the highest OS version that you have reported in your manifest.
You should not be relying on GetVersionEx() to control your app's functionality at runtime anyway. It is fine for reporting the OS version in logs and such (and there are other ways to get the true OS version regardless of manifestation), but don't make decisions based on OS version. For instance, if want to use a given feature that is only available in recent OS versions, don't check the OS version, check for the existence of the feature itself and use it if it is available.
When I run 'meteor update', it says that I have the latest version Meteor 0.8.3. When I specify the release using '--release 0.9.2.2', it says that the version is unknown.
What's going on here?
I tried reinstalling but got the exact same behavior.
Unfortunately, Meteor does not support Windows out of the box. That means that it has to be ported, which takes some time. So if you want the newest Meteor version as soon as it is released, you can either run a VM with Linux (for example, using Virtualbox) or install Linux alongside Windows on you computer (make sure to back up all data before, though!)
Or you can just wait becuase as saimeunt pointed out, Meteor will be ported to Windows soon.
From March 31, 2015, meteor is supported on Windows
https://www.meteor.com/install