Leaderboard

I would rate Windows 2000 9/10. It's new enough to be used as a daily OS. Roytam1's browsers run on it (with BlackWingCat's kernel), and it doesn't consume RAM like the newer versions of Windows do, and has no telemetry. There are some downsides though, like not having any good antiviruses and the fact that not very many security patches after 2011 have been made for it. I have been working with WildBill's files because there is lots of documentation, they seem to be more stable, and there are no stubs. I also plan to document my own changes in a similar manner once I release something new. I don't have lots of assembly knowledge, but I want to learn more and I have the necessary tools to do everything I want to do in the future (IDA Pro, Hex Rays decompiler, UEStudio, Beyond Compare). My current W.I.P. projects (in order from highest to lowest priority): My extended kernel, NVMe support, porting longhorn HD audio drivers. These projects may stay W.I.P for a long while because of their size/complexity and me being busy with school.

This modification would change the 2 to a 4. I presume this blocks NT 6.2 and everything above it. Windows 10 wouldn't need this file due to native DX12 binaries.

Or, if you want to use the original d3d12.dll, I found a check for Windows 8 in here: .text:000000018000622C mov [rsp+270h+VersionInformation.dwMajorVersion], 6 .text:0000000180006234 mov r8, rax ; dwlConditionMask .text:0000000180006237 mov [rsp+270h+VersionInformation.dwMinorVersion], 2 .text:000000018000623F lea rcx, [rsp+270h+VersionInformation] ; lpVersionInformation .text:0000000180006244 mov [rbp+170h+VersionInformation.wServicePackMajor], bx .text:0000000180006248 call cs:VerifyVersionInfoW .text:000000018000624E test eax, eax .text:0000000180006250 jnz short loc_1800062B7 In an hex editor, look for the sequence 06 00 00 00 4C 8B C0 C7 44 24 38 02 00 00 00 48. Change it to 06 00 00 00 4C 8B C0 C7 44 24 38 04 00 00 00 48.

Maybe, but the older Vista DX Graphics Kernel may get in the way (hopefully not, and if so, I hope that expanded ntoskrnl will eventually bring the W7 version to Vista). Apparently they have specific blocks for 8.x too. I just need a copy and I'll look at it.

I found a version block for Windows 8/8.1 in the file, but nothing for Vista. So I think the D3D parts of 368.xx/372.70 are like this: 900 series and below: works on Vista as with old drivers Pascal support added in these new drivers that have no official Vista support, so no workie on Vista Drivers have specific Windows 7 directives, so Pascal probably works when Windows 7 directives are in force. So I think that once I can get the drivers to use the Windows 7 directives, that may be enough to get D3D working as good as Windows 7. Possibly including 12 unless DXGI does not cooperate.

Backup the existing d3d12.dll, and replace it with the x64 d3d12.dll from the download

Resistance is futile.

I'd rather recommend than listening to the FBI but to upgrade your very unique Brain.exe instead. It's the best anti-virus out there. The only downside is, that Brain.exe can't be bought for money and downloading it is impossible, too. It must be fed proper knowledge to grow. And then one day, you will be capable of using the old operating systems online without running into a wall. Would I recommend to average users who use their brain on other things than computers to use Windows XP and Windows 7 for example? No, because that would put them easily in danger. But if you know, what you are doing, then you'll be able to avoid the problems. Use a hardware firewall, that you can configure. Block unwanted Javascripts. Block everything, you didn't ask for. Don't click on everything that sounds like a promising help to your problems. Learn to read links before clicking on them. These things. Also consider that something like Windows XP got more secure over time, as less and less people were using it. Windows 7 is still a very attractive target for mean hackers with circa 15% market share (2020).

They didn't ban my phone after all. I did some modifications: Flashed default LineageOS 14.1 boot image, previously used Magisk patched image, so no more root access in the OS. Full root access is still available in recovery mode. Matched prop ro.bootimage.build.fingerprint with ro.build.fingerprint in /system/build.prop file. Newer Android versions complain about the device having internal error after boot if they don't match. I already took care of other sensitive props before that. ro.build.fingerprint must also match one of the certified devices' fingerprints, though the person that ported LineageOS to Xperia E3 already took care of that. Added a boot script that does "setenforce enforcing". This puts SELinux in enforcing mode. The default on this port is permissive mode. SafetyNet fails if it detects permissive mode. After doing this, SafetyNet check actually passed! And the troublesome app...activated without a hitch. But now the camera doesn't work. Any app that tries to use it hangs. It's a known issue with this LineageOS port not working 100% correctly with SELinux in enforcing mode. Hopefully future build comes that addresses it. Camera was an issue with custom ROMs for this phone from the very beginning, it started with the lack of driver support from Sony for newer Android versions. So what the heck helped? My bet is that the main issue was permissive SELinux. And how to safely test without locking oneself out? If it always talks to the server first before panicking, then the only safe offline test is not possible. If the server is tripped, restoring backup copy of app data wouldn't help. There is the small chance that more checks are in place only during activation process.

Yes, the leaked 2000 SP1 source code. But it wouldn't be a great idea to mess around with it and only about 15% of the entire source code leaked. But someone made a functioning open source kernel32.dll. There are more details about it in his PE Tool thread: Ximonite is basing his win2k stuff around WB's files, so maybe he could take this further. But it does depend on his skillset, which is unknown to me. I don't really know C++, just enough assembly to aggressively patch stuff, which doesn't need source code of course. And then one could advance to creating FOSS versions of other win2k components like ntdll, user32, the HALs, etc. And then go even further by adding desktop composition support, newer DirectX support (or resort to WineD3D or DXVK) etc. These could also be compiled for x64, and we could build a WOW64 framework to go along with that. Maybe embrace .wim-based installs too. Though it will take a very long time for one guy to rebuild the whole OS. There were a solid thousand (probably more) working on Windows 2000 which took over 3 years to make, with 1 billion USD in development costs. To make reasonable progress in reasonable time, this would have to become a dayjob, but how would we able to cover the costs of daily expenses and testing hardware? I wish I were 8-way SMP-capable. One CPU would work on extending Vista, one works on Windows 2000, another one on Server 2003, NT4, Windows 7, one actively learns C (moving on to other things once I'm done of course), one learns C++ (same as before), while the last one does the normal daily tasks expected of a person.

The 15.100 embedded drivers aren't that bad on my HD 6870, and with the extended kernel you don't need to use the powerprof wrapper

I have a R9 380, precisely the point where AMD drivers stopped working. Had to used a hacked together Embedded version of the drivers. Not ideal. Never heard of SDI. I'll have to check it out. EDIT: Yeah, your GPU still had officially compatible drivers with Vista, that's why SDI (Snappy Driver Installer?) found a matching pair.

Maybe u can see from the 32bit version and compare? since it seems like the 32bit apps have no issue with it.

I will work on modding 372.70 usermode components. I just looked at nvd3dumx.dll (D3D usermode driver for x64 components) and I found this suspect code: .text:00000001806B94AF mov cs:VersionInformation.dwOSVersionInfoSize, 11Ch .text:00000001806B94B9 mov cs:VersionInformation.dwMajorVersion, 6 .text:00000001806B94C3 mov cs:VersionInformation.dwMinorVersion, 1 .text:00000001806B94CD mov cs:VersionInformation.wServicePackMajor, r15w .text:00000001806B94D5 call cs:VerifyVersionInfoW So it is actively checking for NT 6.1. No doubt these changes will have to be done for later usermode components. UPDATE: and so does 365.19. So I'll have to check other files.

So are you going to add the 372.70 functions, or mod 372.70?

The incompatibilities are probably incremental. First, official Vista support was dropped after 365.19. Then the user mode DX part of drivers (365.19, 372.70] does not export missing functions, but fails on the officially unsupported NT 6.0. Then 372.90 introduces some missing functions. And the latest W7 ones have like 40 missing functions! The user mode issues, if not corrected, would probably persist once the kernel mode parts of later drivers are fixed. Hopefully the user-mode fix will be applicable to those 382.33 drivers as well as later ones.

So I was checking out this other bank and their procedure to log onto their online services is even more convoluted. And looking at other banks' offerings...the more, I look, the less I'm sure where to go from here. I forgot to mention, there is some extra glitch with Magisk on my device; Magisk normally checks the ro.build.tags prop and sets it to release-keys if it was set dev-keys or test-keys, custom ROMs have it set to one of the latter two. It's written in /system/build.prop file that is generated during build process, which may be modified with rw access to /system. The glitch is when Magisk modifies it during runtime, getprop utility returns the updated value, but a programmatic check through Java still returns the old value unless you modify build.prop file directly. I don't know whether that app checked build tags first or the presence of busybox binary, which, BTW, is actually present on certain official ROMs! I just identified the relevant blocks of code by taking its APK file apart with APKTool. It looks like root checks span across both Java code and one of the bundled native libraries. So the things that I identified are successfully hidden on my phone, at least undetectable by Native Root Checker and RootBeer Sample apps. I also tried registering with the previous version of the banking app, which, in logcat, specifically mentions "negative root check", but no luck, log indicates their server returned some error code. Of course, they could be blocking older versions. Back to the current version, I also tried changing my device's fingerprint, didn't help neither. The thing about blocking my phone's serial number is pure speculation on my part, but this could be it as part of its code does read it. I figured the serial number is passed to the Linux kernel via androidboot.serialno=xxx paramater by device's bootloader. There's also possibility that some hole still exists through which root may be detected. One such hole is known, but can be avoided by using Magisk fork with modules functionality stripped, which I ended up installing, though I haven't found that it's actually used by the app. I guess they could also block the numeric ID they give to their customers to activate the app, but then even using different phone wouldn't make a difference... I also messed around with various versions of Android-x86 on my laptop. It has its own quirks. Good to know ART cache (Dalvik cache in older versions, but still residing in /data/dalvik-cache in newer versions) wasting a lot of space is the problem of Android 7.x in general. I haven't been able to pass SafetyNet test on it, not even the basic one, so there goes the idea of using PC port of Android for that stupid app. Not much positive is written about passing SafetyNet on Android-x86 AFAIK, just some guy hinting using his Magisk module safetypatcher supposedly helps, which just changes phone's fingerprint in a different way during runtime. But since changing the fingerprint directly in build.prop isn't evidently a problem, since I could do it on my phone and still pass the check and the author of MagiskHide Props module, which also changes the fingerprint, says it won't help if one is unable to pass even the basic check, that's just another dead end. Finally, removing Magisk on my phone = SafetyNet check not passing due to custom ROM Downgrading to latest official ROM (Android 4.4.4) = inability to run the banking app at all since Android 5+ is required

I wouldn't mind to pay for this software if it comes with full support for W10. I wonder why BM doesn't release a paid version. If it is under $40 it will sell well IMO

Hi, if anyone is interested, I got VMware Player 16.0 "official" release working on Windows 7. Download: http://69.112.236.57/nextcloud/index.php/s/RWKwBkLoFPdWz93 This is still largely untested, especially the VMware installer is flaky, but VMware itself works very well on my main Win7. You're supposed to reboot right after the installation and then put contents of vmware16_win7 folder in VMware\VMware Player\x64. The video: Edit: Added the VMware Workstation installer. If license key registration fails, try to install VMware Workstation 15.x first, and then directly upgrade to 16.

So this piece of crap anti-virus AVG (or its updater) spammed PendingFileRenameOperations with thousands of entries on my work computer, many of them look like duplicates. I somehow ended up with two exported text files of the said registry setting with slightly different content. One is the current state of the entry and the other is the previous. I remember making backup of the content the last time (actually in May) and it apparently changed until current date. I notice both have some unique entries that are still to be taken care of, not just at the end. There was no reboot since february. So Registry Commander has the most convenient UI for this particular case, I'd just like to merge the two files content and just let Windows do its thing on reboot. Not concerned about anti-virus as much, I could probably just completely purge it via alternative means, rendering its entries in PendingFileRenameOperations irrevelant. It's just that it would be preferable to let the stuff in between that's not related to anti-virus being taken care of, so I figured it'd be the easiest to just paste content of both files in, one after another. But Registry Commander has the problem handling that giant multi-string, which consists of about 15000 entries. Can't paste or type anything new, I can use backspace key on existing entries, but that's about it. O&O RegEditor, which also has suitable editing window, just crashes opening PendingFileRenameOperations setting. I wouldn't have started poking around in registry, but that stupid anti-virus started occasionally showing popup that its GUI is having a bad day (literally). I really hate anti-viruses and other such software, all they ever did was get in my way.