Leaderboard

After reviewing the hard-to-follow discussion in the decommissioning thread, I believe you would need the version mentioned in this post. (I have no need to install Vista at this time and haven’t tried WUMT myself.) Your assumption regarding Server 2008 updates is probably safe.

There are two main schools of thought on the matter. 1) The one I follow (which is objectively more complex to realize) is that first thing "boot" and "system" volumes must be separated, in the case of a Windows NT OS, installing it in a volume inside Extended, and in a multiboot scenario a volume must have a same drive letter assigned in each and every OS that accesses it AND that all volumes should be accessible from all OSes installed. The caveat is that more than a few (poorly conceived) programs will insist on installing (or however using files) on C:\, and in some cases they are a nuisance, on the other hand a (very stupid) malware virus hardcoded with C: or blindly wiping the active partition in the MBR will be able to make much less damage. 2) Alternatively, nothing prevents you from having completely separated installs, with the partition(s)/volume(s) of the "other" OS hidden from the "current" one. This gives a number of advantages, i.e. the install of each OS will be more "standard" so you won't have any issue with programs hardcoded for C:. Both are valid approaches, what I recommend in the second is to NOT have normally the "other" drive/volume visible, the idea is that before or later one is booted in the "other" OS and makes something destructive on the "wrong" volume because of a same volume having different drive letters under different OS. Of course, even in this second situation, the "other" drive/volume in a dual boot can be made visible - in case of need - to repair/fix the "other" OS. Example for #1: 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume (logical volume inside Extended) Vista drive letter D: 3) NTFS volume (logical volume inside Extended) Windows 8.1 drive letter E: 4) NTFS volume (logical volume inside Extended) Common Data/Storage drive letter F: Example for #2: 1) NTFS volume active[1] primary partition Vista drive letter C: (hidden when 8.1 is booted) 2) NTFS volume active[1] primary partition 8.1 drive letter C: (hidden when Vista is booted) 3) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes 1st example for a "mixed mode": 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter D: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter D: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter E: from BOTH OSes Of course there are other possible setups, including having the small FAT32 partition have not a drive letter assigned normally, which is what more or less is already happening on UEFI/GPT disks, i.e.: 2nd example for a "mixed mode": 1) small, FAT32 partition primary active no drive letter assigned 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter C: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter C: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes jaclaz [1] this approach needs a bootmanager capable of changing the active status of the partition and hide the "other" one at boot time

As of August 2020, WU will no longer work with Vista no matter what patches you manually install. There has been some discussion in the decommissioning thread that a suitably old version of Windows Update MiniTool with a suitably old version of wsusscn2.cab might still be a workable automated solution. Aside from that, we have a download links thread and a Windows Vista Update Repository thread.

I did think about adding code to ignore WASM related prefs when SSE2 is not detected.

The exact URI to that script is https://game314425.konggames.com/gamez/0031/4425/live/Build/UnityLoader.js I downloaded it locally on disk and probed it with an editor ; I couldn't find "Disabled by lack of compiler support", but did find the original warning/error: "Your browser does not support WebAssembly." Looking closer at your Web Console output, it appears the message is generated by the browser's asm.js module, when it tried to compile js code fed to it by the UnityLoader.js script ; BTW, many thanks @UCyborg for your most helpful contribution, as always : You might've mentioned it previously in these forums, but it didn't dawn on me that that was the case... I am running Vista SP2 32-bit and my 2007 era Intel Core 2 Duo is SSE2 capable; so using the "-xpmod" variety of Serpent-52.9.0-win32... By the looks of it, you should be running the "-xpmod-ia32" build, derived from the "ia32" branch of Roytam1's UXP fork: https://github.com/roytam1/UXP/commits/ia32 TBH, I don't follow closely the development of that branch, only that of the custom branch (produces NM28+St52)... @UCyborg wrote that WASM expects at least SSE2 instructions set , so there's your answer... @roytam1 : Perhaps it could be a good idea to disable WASM and LOCK the related prefs (inside about:config) in your ia32 builds, so as not to create false expectations by the users of those builds on their pretty old processors... Just throwing this out there for consideration... As posted, I first tried the site with a pristine St52 profile, and it did ask permission to use Flash; Flash is used to deliver ads in the embedded player, just before the game itself loads (when it does... ).

Is it me, or lots of people think that WiFi == Internet?

It comes from the browser. One of the checks that must pass for the browser to even bother with WebAssembly is SSE2 capable CPU. The base site seems to work without it, looks like some hidden Flash file lurking in the background. Flash games obviously won't work without it.

WinNTSetup 4.2.3 - fixed Vista images could be applied in compact/wimboot mode - fixed compact:xpress4k using 8k compression with newer wimgapi.dll - fixed some command line ini option combinations - fixed vmware mounted drives disappear on winntsetup exit - new cmdline option regtweaks support wildcard file pattern - new scan offlines services to exclude Driverstore *.sys files from WOF Compression

Remember a while ago when we were talking about 0patch and I said that I was wondering whether to buy it or not? Well, I bought it a month ago and it's been working fine so far. I also just received three new patches today. I didn't notice any incompatibility either so far. I think this is the closest thing we can get to the Microsoft Premier Support and its extended updates without paying an eye and a leg. https://i.imgur.com/1Y87o5D.png