I have an NDIS 5.x Passthru driver that was adapted from this sample. Obviously NDIS 6 has been available for quite some time, rendering 5.x obsolete, but backward compatibility has allowed the driver to continue to run in up to and including Windows 8.1 so the code has not been updated.
Now the same driver does not function on Windows 10. (Edited to add: The driver loads, but "netcfg /b" shows that it did not bind to any adapters.) The sys file is the same, installed the same way and with the same signature that works in Win8.1. I can't find any official source that NDIS 5.x compatibility has been removed from Windows 10, but I do find several people with the same problem who are speculating that is the case.
Do we know officially if NDIS 5.x compatibility been removed from Windows 10, and/or is there some kind of compatibility mode that can be activated to allow me to keep using my existing driver until I come up with Plan B?
No, NDIS backward compatibility was not removed in Windows 10. A new network class Installer called NetSetup was added with a shim for the old NetCfg calls. Apparently, there's a bug in the shim that causes drivers like mine to install but not bind to any adapters. They're assigning someone to work on it, and I will update this answer when there's a resolution.
Edited to add: Microsoft has decided not to resolve this issue because few are affected by it.
Related
I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)
As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.
Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer
Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.
The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?
I come across the following link - https://github.com/felixrieseberg/windows95
Running windows 95 as Electron APP
Is it possible to create any existing application as portable or cross-platform using electron like above?
Can we use Windows 7 or 10 like above without Oracle Virtual Box or VM in an existing Windows 8 machine ?
Need more details on how it is possible to bring an application via electron
Thanks.
If I'm hearing you right, you're wondering if you can put a whole OS into a JS VM running in Electron - and then run your app on top of that.
Please don't do that. Electron is a fantastic cross-platform solution, but my project windows95 was mostly an educational experiment showcasing how powerful modern JavaScript and Electron can be.
This project uses another project called v86, which is capable of virtualising a x86 platform and display its output on a HTML element. Electron is browser-based so that is why this works.
But there are some limitations: It virtualises the x86 platform, which is pretty old by now, and when you have a look at the specification, it says it is at a Pentium-1 state. The demo links on the project's GitHub ReadMe also do not contain any "modern" OS because v86 does not support SSE(2). And since Microsoft requires its users to have a SSE2-compatible CPU* it is not possible to run anything like Windows 7 or newer (Linux may work, anyway).
OSses which support this kind of (deprecated) hardware, may work. As you can see from the "Compatibility" section of the project's ReadMe, some Linux versions and Windows XP "work" but older software, like OS/2, and even newer stuff, like Android, don't (really). So you can't say that everything will work as expected because the execution environment is really limited.
Now to answer your first point, no, I don't think that you can wrap every existing app into an Electron application and run it on new hardware. It may work with old software (which do not require SSE, if you use v86, and that would require a lot of hackery on the v86 side because it is designed to run OSses), but don't quote me on that.
* The section in question reads (at the time of writing) like this:
A Stop error occurs on computers that don't support Streaming Single Instructions Multiple Data (SIMD) Extensions 2 (SSE2).
Upgrade your machines with a processor that supports SSE2 or virtualize those machines.
(emphasis mine, source: https://support.microsoft.com/en-us/help/4088875/windows-7-update-kb4088875)
An application's minifilter driver is working fine in windows earlier than windows 10. I want to make it work in windows 10 as well. Need help!!
I'm unable to figure out the causes in Windows 10 as the driver is perfectly working fine earlier to Windows 10 versions.
Driver requirements (superuser) including driver signing requirements (ms blog) have changed in Windows 10. You will most likely need a new driver as I think there will be no work-around for most driver problems in Windows 10.
The issue I had was due to an old audio driver and I had to manually pull down a different driver with a newer date from the hardware suppliers site.
If you want more information on the actual problem, look to the windows event log, or driver debug logs. For example Microsoft's website says:
If a signing problem exists, SetupAPI will log information about the signing problem in the log file. The name of this log file is SetupAPI.dev.log, and it is located, by default, in the Windows INF file directory (%SystemRoot%\inf).
XInputGetKeyStroke seems to return ERROR_SUCCESS when the specified controller is not plugged in, leaving the supplied XINPUT_KEYSTROKE struct uninitialized:
XINPUT_KEYSTROKE xStroke;
DWORD ret = XInputGetKeyStroke(0, 0, &xStroke);
if (ret == ERROR_SUCCESS)
printf("ERROR_SUCCESS\n");
Am I doing something wrong or is this a bug in XInput? xinput1_3.dll is the version I am using. I am compiling/linking against the headers/libraries in the DirectX 2010 SDK. When the controller is plugged in XInputGetKeyStrokes seems to behave as expected.
I've had the same problem with xinput1_3.dll and from my research it seems it is not implemented. It may be implemented on xinput1_4.dll on Windows 8 but I am unable to test this.
Confirmation that it's not implemented as of 26th April 2014: http://controllermax.com/forums/archive/index.php/t-142531.html
Not the most acceptable of sources but it's all I could find.
Support for XInputGetKeyStroke was added for XInput 1.3 (April 2007), but no Windows driver supports the 'Chatpad' device so it's limited to the controller "button keys".
The source for this function did not change between XInput 1.3 (the last version available down-level on Windows 7 via the legacy DirectX SDK / DirectSetup) and XInput 1.4 (the current version on Windows 8.x), so if there is a bug here it likely repros on XInput 1.4 as well.
This particular API is really only useful on Xbox 360 where the 'Chatpad' might be supported, and due to the down-level story for XInput, you are usually better served using XInput 9.1.0 rather than XInput 1.3 and sticking with the standard XInputGetState methods anyhow. I don't use XInputGetKeyStroke at all for the DirectX Tool Kit GamePad class which is probably a more useful abstraction.
See XINPUT and Windows 8 and DirectX Tool Kit: Now with GamePads
UPDATE: I found the code path that resulted in this condition, and will file a bug, but it's not likely to get fixed for XInput 1.3. One workaround would be to use another function (XInputGetState or XInputGetCapabilities) to check for connected state, and then call XInputGetKeyStroke only if it is connected.
Code snippet:
navigator.plugins.refresh(false);
var a = new ActiveXObject(collab.axName);
if (a) {
version = parseVersion(a.version);
}
I run something very similar to the above to check the version of my installed FB plugin. If it is out-of-date, I replace it with a newer version (Firebreath bog-standard Windows installer). However, if I run the snippet again, the newer version is not detected - the new ActiveX object has the old version number.
The ActiveX object creation seems to be the key - installing an update before creating an object will work correctly, and the update is detected if the browser is restarted. And updates work fine in NPAPI browser (which do version detection using navigator.plugins).
Internet Explorer 10, Windows 7.
My question:
Is this expected behavior (or indicative of a bug in my code)? If it is expected, is there is known workaround or alternate approach to accomplish the same goal of installing an update without restarting the browser (e.g., version detection without instantiation, forcing ActiveX update detection)?