win32

The downloads at this link seem to be fine. https://packages.vmware.com/tools/releases/10.3.10/windows/index.html I think they're stuffed in the ISO.

4.6.2 also is causing the same issue with the VS installer. I'm going to check if a specific function is causing this (using the method I recommended for KernelXE) and then hopefully fix it. Older and simpler .NET stuff continues to work in my experience though.

I should chime in on this, as I have some of my own issues with .NET. 4.6 seems fine to me; it is the minimum version required to launch the Visual Studio Community Edition installer. Haven't bothered with it enough to go past the "Windows 7 SP1 required" message, but if I have to I will. 4.7.x (a very recent finding of failure for me for this one) and 4.8 however, cause this and a few other newer .NET 4.x programs to crash. 3ds max 2021 is .NET 4.8-based and also crashes after launch. I'm trying to figure it out, but it is harder to deal with .NET than pure win32.

When that dialog appears, dump files are erratically written. You can view them in Dr Watson (drwtsn32.exe). They can be helpful, but in this case they're just as useless as those. As we have no idea what is causing these issues based on dumps and dialogs, we can use local redirection to help us. Go to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs and delete most entries (except for the DllDirectory one or else you will get a BSOD on bootup), including the one for kernel32, reboot and then copy/paste the stable kernel32 to the CFF explorer folder, make a file named CFF Explorer.exe.local, so you will be able to use it. Then find a known broken program, copy the unstable kernel32 to its folder and do the .local thingy again. Comment out its calls in the same way using CFF or similar utility until you can get it to launch again. I've had this red herring crash problem before. Chromium 73+ was shown to have crashed on an import call to RtlOemUnicodeString or something like that on Vista originally, but it turned out to be a few incorrect call near ptrs (those can only be done if calling a routine within the same section, when they were indeed calling routines in other sections).

Haven't been able to run it yet (woah, it's almost 60 GB!!! mostly play older games that are a few GB or less) but I don't see any traces of mono. Checking the dependencies, it should run on Windows 7/Windows Vista Extended Kernel, which means another developer is lying when they put Windows 10 as the minimum OS.

The plural was an oversight. It appears that only one .local file is needed per folder; other executables in the same folder seem to use the local DLLs as well. Well, that is odd.

You would have to put the files and the .local file in the game exe's folder, since that will ultimately load the mono files. And 0xC000007B means that the file image is bad (corrupted), possibly caused by modifications made to the file.

Yes, there are PAE patchers available: https://wj32.org/wp/2016/02/01/pae-patch-updated-for-windows-10/ (should be OK to post, as it simply patches existing ntoskrnl/winload)

I do have a game that uses MonoBleedingEdge, Crisis in the Kremlin. Steam page said it ran on XP x64, except it didn't. Mono (which is .NET) was the problem. And it got to the point where it stopped working on Vista as well. Indeed, I have a copy of the file mono-2.0-bdwgc.dll with a digital signature dated January 15, 2020. The Windows 7 function TryAcquireSRWLockExclusive is called by that file. Because I added it, that game is working again. What about your mono files?

Point taken. I just checked and I see they are more similar to yours than the Vista versions. Thanks for that info anyway, it will save me from having to port the SRWLock stuff.

Yes, it does have some disadvantages over direct file replacement. I noticed some issues with the Firefox search bar and playing media in that browser with redirection alone. Never tested it with chromium.

I just glossed over the Fls* series of functions. And it's not the most faithful implementation of some of those, when compared to the real Vista ones. I'm about to put those in XP's kernel32 for someone. How are those SleepConditionVariable* functions that were problematic with KernelXE coming about?

Yes. nvcpl.dll, uphclean.exe and Internet Explorer also don't load. uphclean crashed after several calls to FlsAlloc/FlsGetValue/FlsSetValue/FlsFree then EncodePointer/DecodePointer. Internet Explorer crashed after a CreateActCtxW call. Perhaps see what happens after commenting each of those sets of calls (replace last character with "_"). Had some Windows 8 functions prevent Vista from properly booting.

It was listed at the top of the post. Forgot that v17 was also there farther down or that it existed. It's been a few months since I messed around with WB/XE files.

You should install WildBill's updates before installing kernelxe as it's based on those files. http://www.mediafire.com/download/vdbwx67dx34jezj/Windows2000-KB2479629-v3-x86-ENU.exe http://www.mediafire.com/download/1agd8icjjbu5s4n/Windows2000-KB2508429-v17-x86-ENU.exe I'm so excited just to have full raw input support. Just waiting for school stuff to quiet down and I will have an SSE-only test box.

Yeah, that shell32 error is a weird one. Never had it myself on my testing systems. An installer will soon replace this method. osloader.efi is intended for UEFI systems only. There's no real need for osloader/ntkrnlmp as of yet, actually. huh? This should be sufficient as it updates the main OS files (like win32k.sys) and is what I used.

You do need to go further than base SP2. Anything from April 2017 to present is good. For a quick rollup-type update, this one works for me in some of my testing VMs (November 2018 rollup): http://www.catalog.update.microsoft.com/Search.aspx?q=KB4467700

Try the offline version: http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe

Ever since I purged some of the hyper-experimental DLL stuff and reinstalled Vista, my boot time has gone down to about 25 seconds, same to slightly faster than XP x64 and 7.

strange. It is hosted on a semi-abandoned WordPress site of mine.

This is the original version of Teardown, which uses a Windows 10 exclusive API function, SetProcessDpiAwarenessContext, running on Windows Vista with an upcoming update to user32.dll: Later versions of the game no longer use this function and as such will work normally on Windows 7, 8.x and 99.9% sure, Vista, though I have no proper way of testing DX11 games on Vista due to the age of my GPU. There are also other games known to use this function, so even though the developers of Teardown realized the demand for their games on older platforms, others may take a different attitude and force users onto the latest versions of Windows 10 to use their products. So, this will allow Vista/7/8.1 users to be prepared for such a future event. Since some interest has been shown in donations for my work, I have set up a method for users to contribute financially for this and some of my other works: https://www.patreon.com/win32

On two separate machines, I've had significant difficultly printing with an HP Officejet 6600 and "printing" Word 2007 documents to PDF. Communication with the printer devices is very slow/nonexistent at times. Anyone else had problems?

You don't have to limit yourself to < 1 GB (some very recent motherboards leave that for 32bit OSes), 3.5 GB or 4 GB when you enable/un-cripple PAE. http://www.geoffchappell.com/notes/windows/license/memory.htm?tx=7 Server 2008 Enterprise and Datacenter x86 (not sure if Standard's RAM limits were upped from 2003) also allow the use of the extra RAM without modifications.

Mostly using this config: -Intel Xeon X5670 2.93 GHz 6C/12T -12 GB DDR3-1333 -NVIDIA Quadro FX 3800 (which is like a GTX 260; I think Santa will bring something that brings me into the DX11 age ) -1 TB 7200 rpm HDD (a WD Purple IIRC) -500 GB 5400 rpm Seagate HDD I remember when Vista came out and always wanted to use it, but only got to use it 12 years after release. And now look at me. Since I first heard about kernel extensions, I always wanted to make some, though my attempts were always unsuccessful. At one point towards the end of 2019, I was experimenting with changing new win7+ functions to older ones present on Vista, specifically for Waterfox Classic. I got the UI to load but it would crash immediately. Then I learned more and more about the process and decided to choose an OS where a kernel extension effort would: -not overlap with existing ones -be plausible -and also be workable on my bare metal So I chose Windows Vista! Vista takes about 40 seconds to boot for me, compared to about 25 seconds for XP x64 and 7 x64 on my main workstation with a 7200 rpm HDD. While the boot process is quite uniform for me on XP and 7, the sequence can be quite erratic on Vista, with the periods of ntoskrnl-stored startup screen and blank screen with cursor (pre-orb animation) seemingly varying in length per boot (sometimes my monitor gives me a no signal message post startup-screen; other times it doesn't). Perhaps fragmentation is a factor (I have Vista follow the standard weekly defrag schedule), but I also see a possibility that this occurrence of boot time variance to whatever is responsible for causing usermode (don't believe I have seen kernelmode components fail to load) library/executable load failure on Haswell and up. This in itself is a major Achilles heel of the operating system and needs to be resolved somehow if I were to successfully create kernelmode extensions that allow hardware typically accompanying recent CPUs to fully function. X58 is period correct for Vista and my machine does work very well with it. Just wondering; do you have indexing and SuperFetch enabled? That's responsible for most of it, and both should definitely be disabled on an SSD. I had noticed that my disk I/O indicator light was on constantly for awhile; Process Hacker said it was a low-priority read operation by a system process on a Vista ISO I had recently used in a VM. After disabling SuperFetch, that stopped. It's not going to be of much use if it's going to be for something used so rarely. The SuperFetch algorithm must have prioritized it so highly because of its size and recent usage.

I haven't much interest in Chromium/Blink myself, though I test it and support it based on popular demand. The only advantage Chromiums have right now is that they are currently the only Vista-compatible browsers capable of viewing Widevine-protected content.