win32
Content Type
Profiles
Forums
Events
Everything posted by win32
-
strnlen. Maybe it could be temporarily replaced by strlen.
-
The 38x drivers actually added a function that was removed from the 39x versions, which I did not add yet. Oddly enough I do have notes about 382/384 drivers, which apparently reached a black screen instead of outright crashing (or producing an orb). I suppose I could add it soon. The orb may be caused by conflicts with other drivers. Do you have a discrete NIC and/or are you using unofficial USB 3.x drivers?
-
The Chrome version 110 will come out in February, and Chromium-based browsers and applications will base themselves off 110 starting from then. Right now it is still somewhat obscure. Opening a file and checking its version information would be slower than what GetVersionEx does, which is to make a call to another function which accesses a data structure located in memory. But Chromium already did both and still does now. I think the big difference is that some Windows 8+ specific code paths are still being skipped in Opera.
-
The October 2020 version works if it is set to "big picture" mode. You will see store information and everything. But sometime after that, the login window switched to being rendered by CEF (Chromium) so it is not possible to sign in as there is no text, graphics or buttons on the login screen now. As for the Intel drivers, I have a couple of systems that can use them but they are in very poor shape. Various differences in rendering quality are known to exist between Vista and 7 and I don't want Vista to be compromised by any changes I do. So I'll try to do something that doesn't "change" Vista to its detriment. Also, the Vista extended kernel will be able to run Chromium 110 and 111, at least with --no-sandbox. I will try to get the sandbox working in time for the main release of Chromium 110 in February. I am adding the appropriate functions to kernel32 and userenv. I just checked the Chromium source code and discovered that the version nags are persistent now because they are not calling GetVersionEx* or similar to check the version, but they are checking the version number of kernel32 instead.
-
Interesting result. But I won't be able to get the 7601 d3d9.dll easily, as all the dependencies are effectively in win32k or the DirectX graphics kernel, much like with the Vulkan support in the NVIDIA drivers. The 6936 or 7000 versions may be easier, but they are not final so I would risk introducing further instability.
-
Based on my experience with Vulkan on Vista-compatible NVIDIA drivers, I would not be so quick to pin the issues on user-mode components. I'm not sure if there were any major changes to D3D9 since Vista brought in D3D9Ex. I would have to do a binary diff of the Vista SP2 and 7 SP1 D3D9 binaries...
-
Standard 32 bit Chromium works as well, including extensions. But Steam and Discord do not work properly yet. Steam can connect to the Internet again, but the Chromium parts of it don't display anything and logs are not very helpful at this time. They are continuing to add functions to Chromium 111, and I was able to run that with --no-sandbox, but not with sandbox yet.
-
It would be the latter, just like how they tried to remove Aero Glass from Chromium on Vista. Everything going forward is to target Windows 10. Honestly if they want to break it properly on Windows 8.x, they just have to move some of the DPI functions from being delay-loaded to the main import table.
-
Very low at this time. I was able to run all the 39x without issue unlike many other people, and I couldn't even boot with 411. I don't use those either. The only purpose they serve is to name devices in Device Manager. Some of the 39x users thought that the unofficial USB drivers may have not worked well with the GPU drivers. They worked good on my Kaby Lake laptop, but I do want to get official USB drivers working as well. -
Unfortunately I don't know any Titan XP owners.
-
The error code that produces the message associated with the logon procedure failure can come from a wide variety of functions; when I was using a Kaby Lake laptop I tried to debug it. But debuggers would fail to run! So I would have to return to the laptop, change every reference to the error code in ntdll/kernel32 (and a few other lower level DLLs) so each one returns a unique error code (so one function would return a message associated with error code 85, the next would return one associated with 86) to identify what exactly is failing in there. Unfortunately the build quality of the laptop is very poor so it cannot be moved easily, as it can't be closed without risking the screen snapping off (and thus it's not where I actually live). You can't dictate what any user can or cannot do. The latter two are focused on Windows XP anyway and there is no telling how successful the HAL wrapper will be. But if it is, it will give me more flexibility in modernizing parts of the kernel.
-
The processor driver is primarily for power management, so it would probably not do anything. I might try my luck with a HAL wrapper eventually, as that seems plausible due to the kernel resolving export forwards for NTOSKRNL and HAL (but no other kernel mode modules, though the Xbox kernel might be different based on its inclusion of MmGetSystemRoutineAddressEx which works on all kernel mode modules). The binary patches to the HAL were not cutting it and I could not implement the TSC correction in any form as the system would get stuck in fence loops on boot. And if export forwards don't work out, there are only 81 exports to duplicate in 6003's HAL. But I still have to get NVIDIA 4xx drivers, make NVIDIA 36x+ work 100% by adding functions for Vulkan and OpenCL, not to mention the Windows 10-compliant implementation of job objects. And all kinds of odds and ends along the way! This morning I got very annoyed with continuing printer driver issues on Windows 8.1 (and 10 is not much better). Nothing like that on 2000/XP/Vista (and maybe not 7 either).
-
Some users could not get the system past the "orb" when booting using 39x. I can't reproduce it myself, making it hard to fix. I am working on getting 411.xx with my kernel as well.
-
As 398.11 seems very hit and miss, I would try 391.35 or 399.24.
-
It should not be a problem, although I am trying to get many new drivers working at this time as well. Not just the newer 4xx drivers for the newer Pascal revisions and RTX, but also for some other unfortunate devices I've come into lately like WLAN dongles that only support 7 or even 10.
-
I don't have an install of Windows 7 to test at this time, but I think it should react similarly to Vista because Windows 8 introduced some of the necessary job object features, while Windows 10 introduced the rest.
-
You can't run anything Chromium if it's version spoofed to NT 6.2 or greater for now, because of the use of features that aren't implemented right now like job objects.
-
I think it's equally as hard to get Chromium back on Vista and 7. I'm sure it will be done. And it still works on Windows 8 with --no-sandbox for now.
-
Now we are on 110.0.5425.0, and it will no longer launch on a regular Windows 7 install. Three functions needed so far: SetThreadInformation SetProcessMitigationPolicy GetProcessMitigationPolicy These are all wrappers to older ntdll functions, so they should be easy to add, to some extent. If not, this new code is all in the sandbox anyway.
-
Official Chromium browser snapshot 1070779 (110.0.5417.0 - at https://storage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1070779/) is available today. No work has been done to break Windows 7 compatibility yet. Vista and 7 will have a harder time because of the lack of support of nested job objects in those operating systems. Though even if VxKex and Vista Extended Kernel are unable to enhance job objects in time, I think we can run them with --no-sandbox in the interim. as most of the code relevant to job objects is in the sandbox.
-
If I can confirm that the wrappers will allow me to add the functions without breaking applications, then those functions will return. But have you tried 64 bit DX11 applications and games? If those don't work then it must be something else.
-
All of them except for COMCTL32. x64 only for now. I should be able to add them back to x86 soon.
-
It may have something to do with the patched version of ci.dll in the extended kernel. It verifies signatures of some other system components.
-
I did not. I think the point of failure would be even earlier if signatures were checked. But on another note, I noticed that the included OpenCL runtime in 398.11 is missing a function in CFGMGR32. But I think an older one can easily be used, as most of the important OpenCL features were introduced about 10 years ago.
-
Windows 2000 modified driver packages also had problems with the CPL as well. I have CPL version 8.1.950.0 on my 398.11, but I upgraded from 372.70. It also is missing most of its options. (actually, 398.11 comes with 8.1.940.0, so presumably 8.1.950.0 comes from a failed experiment with 411; but even then, some 2016 files were still present) But you say that you can use 38x without CPL and it works, but if it is installed, it freezes on the orb? I thought it had something to do with other PCI/PCI-E cards being present, as I know that a few others got stuck on the orb with those, while I don't have any aside from the GPU and I did not get stuck on it.