Tripredacus

UEFI 2.3.1 is the current standard and many boards come from factory with no CSM. So many people do not have a choice these days. Also, UEFI does not have a bitness involved. The architecture capabilities of booting a UEFI application is based on the processor. The manufacturer of the board decides whether or not to allow a user switch or lock UEFI applications to a particular architecture. To my knowledge, there is no fully limited firmware out there, all are modified to meet the design requirements of the ODM. There is also the video card consideration where many video cards from the past few years are UEFI only.

Sorry, I haven't used anything from nVidia since the 210 series.

I don't end up using those programs as a first attempt in most cases. Since I have an imaging server, I tend to attempt to copy the partition image to the server and deploy it to the new disk as if it were a new installation. Sometimes that doesn't work and I have to hunt for some program to do it, but rarely has that happened that I don't even remember what programs I had used to resolve those issues.

It is in the kernel32.dll from Windows 10, so try copy that to the working dir on the game and see what happens.

That is for 2 servers, but single server is actually quite simple (meaning you don't have to do most of the stuff in the first post), especially in the newer Server versions. 1. DC Promo 2. add the DHCP role 3. add the DNS role 4. add the WDS role 5. add the boot image to WDS Obviously you still need to pre-plan the network environment, which scope you will be using, the domain name, which users to assign to the shares, etc. But there is a caveat involved when dealing with PXE. You want to determine whether you are going to be doing MBR or UEFI clients and stick to that one only. The issue is that the WinPE still has a bug involving diskpart where it cannot make MBR disks if booted in UEFI and WDS still does not properly detect some LAN card capabilities (meaning it can provide boot loader for "wrong" boot type, and thus diskpart runs the wrong scripts. I personally only use the WDS portions now do to MBR or legacy installation and just boot my WinPE boot image on USB and bypass WDS entirely for UEFI (which is like 99.999% of installations at this point).

Status doesn't matter. Read the forum rules.

Removed from where?

I don't have that specific disk to try, but in general I haven't heard of any particular issues with any OS working on SATA SSDs.

Just on socket, since no board is being considered... It would be Pentium Extreme 965 3.73 GHz at 1066 MHz https://ark.intel.com/content/www/us/en/ark/products/27615/intel-pentium-processor-extreme-edition-965-4m-cache-3-73-ghz-1066-mhz-fsb.html vs your example of the Pentium 4 570J, 670 or 672 3.8 GHz at 800 MHz Now the other thing to consider is how you would even be able to tell in any real world application as to which is faster in DOS.

Seems this notebook is extremely old for modern computing, so it would seem to indicate that it has an older version of Windows. Since you don't say what version, this may not be applicable but... Use F8 at boot time to get the boot menu, and choose disable automatic restart on system failure. That should stop the reboot from occuring. However if this is not working, then you have some other options such as booting off removable media. If this is the same 8922 that searching shows has 1 GB RAM, you can boot a WinPE 3.0 on it, or a Linux live CD. Also if you think that the system is restarting before getting to Windows, you can remove the HDD and turn it on and see if it resets that way. You should go into the BIOS and enable LAN booting just so it can get to that point (you aren't meaning to boot that way). Also going into the BIOS and resetting to defaults is not something I would recommend. Primarily because the OS may not boot if the SATA type was previously IDE and the default is AHCI. Or on a modern system where CSM was enabled and default is disabled, etc.

I remember something like this happening without going through those steps. I don't remember the timeline exactly but I had reported the issue with MS. I don't think it was the entire OS that looked like this.

It can be done with DISM also but you'll need a third disk or network share to store the image temporarily. In this method you do not need to transfer the hidden partitions at all. I can put a workflow here but will need to know what the current partition layout is now and if the disk is mbr or gpt type.

The forum doesn't keep email address history. It can't show me who had a live.ca email in the past and had since changed it.

No user has registered/used with a live.ca email since 2015 but that email domain is not being blocked by the forum. The issue lies elsewhere.

Not sure about 2000 but for XP you can use WSUS

If the issue is that the image is too big, they can use imagex /export to see if it reduces the filesize. Maybe DISM export does the same thing.

Not going to happen on a ban on rule 1.

We can probably not count Wolfenstein: The New Order at this time as using 3 api files from Windows 8.0 and copying the kernel32.dll from Windows 7 and renaming it as api-ms-win-core-file-l1-2-2.dll allowed the game to actually launch. I was really expecting it to keep asking for more different files to hunt down but glad enough I can actually play this game. So this can be a way to try to get programs to work in Windows 7 but only those programs that aren't doing a hard check on the OS itself. And now my Windows 7 PC has joined the old tradition of my Windows 98 PC as having future OS files in it to run programs it isn't supposed to be running.

I had tried doing this, but the game then complains about missing entry point for GetVolumeInformationA, which if this is correct: "Introduced into api-ms-win-core-file-l1-2-2.dll in 10.0.16299." https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis It is the only location. So while my OS may have a GetVolumeInformationA entry in kernel32.dll, the game is not calling that because it is trying to do it with that specific API. And the APIschema is mapped into memory and the file-l1-2-2 is not present at all. This file is one of the few that doesn't actually seem to exist, as it is (was?) mapped to kernerlbase.dll in Windows 10 from its own schema. I do not know if there are any integrity checks that would be done, perhaps having a dummy .dll file present that just redirects the call to kernel32.dll would work but I haven't a clue on where to start. I suppose I could take the kernel32.dll from system32 and put it into the workdir and rename it to core-file-l1-2-2 and see what happens.

I was excited that this would be some magic bullet but alas it only resulted in generating a 0xC000021a bugcheck on reboot. I'd rather not have to bother with that any longer and would prefer to source the file it wants instead. It was not present on my Windows 8.1 test system, nor my Windows 10 workstation. Searching online doesn't easily reveal where the file comes from.

Updated

As I had suspected, there is a rabbit hole involved here. I had made a copy of the entire DLL set from Windows 8 and 8.1 just in case it wanted more. And it did, and I had to put 4 more DLLs from Windows 8 into the working DIR. It still has not opened, as it needs another DLL that I didn't have and will have to see what happens after I find that one. EDIT: the file now missing is api-ms-win-core-file-l1-2-2.dll, which leads me to an interesting post on stackexchange here (just don't read the comments) https://stackoverflow.com/questions/69943334/newer-windows-sdks-cause-api-ms-win-core-file-l1-2-2-dll-missing-on-windows-7-8

I don't even have the moon button anymore.

The build of Wolfenstein: The New Order from Epic Games does not open on Windows 7. It requires a file api-ms-win-core-com-l1-1-0.dll which is said to be in a VCRedist but it is only from Windows 8 (or 10) and does not get installed on Windows 7. I did not try to get this file from a Windows 8 system to see if that allowed it to run or lead to any other message.

The topic title doesn't make any sense.