It depends on the game. In general, considering all of the games produced during the 95 period it would be "hit or miss".
Several considerations are that NT 4 did not get the same later versions of DirectX as Windows 95, and many games produced during the 95 period were actually still DOS games.
The more well-written Win32 based games took both 95 and NT 3.51/4.0 in to consideration.
Keep in mind that 3D OpenGL games that supported NT 4 required an NT compatible and sufficiently powerful video card. Some video cards only provided 9x drivers, or drivers differed in capability.
Activate plug and play device detection in Windows NT4: 1- Locate the Pnpisa.inf file in the Drvlib\Pnpisa\ folder (ex. x86) on the Windows NT 4.0 CD-ROM. 2- Right-click the Pnpisa.inf file, and then click Install on the menu that appears. 3- Restart your computer.
Also getting a virus warning on the Server ISO (Trojan:Win32/Vigorf.A). A quick search seems this comes up with lots of different AV tools and different ISOs.
Yes. I can. In fact, exercise a little critical thinking, and you can explain yourself. The comment immediately before yours gives the all important clue. Then, if you actually LOOK at the archive, you will see the ISO is dated from 2014.
And then you might ask yourself: "hmm is it reasonable to expect, that a file that has been archived for 11 years only now should be infected, and that I am the first to be aware of that?"
Aren't 86box, PCem and QEMU just basic emulators? I never heard anything as a metal emulator, probably something like emulating the hardware down to the microscopic level.
86Box & PCem are hardware emulators, they emulate the hardware in software. Think the likes of console emulators, MAME, android emulators etc etc. The hardware doesn't actually exist physically, its recreated in software and run as a binary.
QEMU, Virtualbox & VMWare Workstation are hypervisors, in some cases they don't emulate most of the hardware (I'll explain this below), instead they act as a bridge between the VM and the system hardware. In a hypervisor the guest sees the host CPU and its possible to pass through physical devices like GPUs, USB devices, sound cards etc etc through to the guest. The host intercepts the hardware calls made by the guest, processes them and sends them back in the correct format (and given that modern CPUs still have 99.9% support for the OG 8086 CPU spec, not much processing is required)
They absolutely can emulate when needed, for example when you install NT4 on VMWare, it wouldn't be much good to pass it a modern NIC so it emulates a PCNET instead. The same is true for motherboard specs too, most hypervisors will emulate the base platform for older OSes, this is necessary for the same reason, passing NT4 a modern NVMe HDD controller is pointless.
In principle though, and as long as you are using an OS newer than the Q35 spec, the VM will be using the system resources as though it was running on the machine. This is why its still necessary to patch Windows 9x to run on hypervisors, modern CPUs are so fast they outpace the timers on OSes that old and the OSes really don't like it when the IRQ bus is running at 100000x what it should be, just for one example.
A metal hypervisor is simply a machine that is running a hypervisor as its OS, Vmware Sphere, Proxmox etc etc. These have one major advantage over a "software" hypervisor, if the OS is a hypervisor it can boot itself up using the bare minimum system resources and hold the rest of the hardware off the bus so you can carve it up between the guests with much more accuracy and control. If you've ever tried to get QEMU to pass your GPU to a Windows VM under Linux, you know the struggles with all the scripts you need to stop the card, remove it from the bus and pass it through so the OS can use it, metal hypervisors solve this by never initialising the card at all until the VM needs it, no scripting needed.
Anyway, now thats out of the way. For future reference and in case anybody is stuck. To get NT4 installed on VMWare you need to power on to firmware, change Multiprocessor spec from 1.4 to 1.1, change installed OS to from Other to Win95, save, boot NT4, during the setup at the screen where you can change your keyboard layout you change the System field from MPS Uniprocessor to i486 with C Step support. This will stop it from KPing after the first reboot.
Comments
Several considerations are that NT 4 did not get the same later versions of DirectX as Windows 95, and many games produced during the 95 period were actually still DOS games.
The more well-written Win32 based games took both 95 and NT 3.51/4.0 in to consideration.
Keep in mind that 3D OpenGL games that supported NT 4 required an NT compatible and sufficiently powerful video card. Some video cards only provided 9x drivers, or drivers differed in capability.
1- Locate the Pnpisa.inf file in the Drvlib\Pnpisa\ folder (ex. x86) on the Windows NT 4.0 CD-ROM.
2- Right-click the Pnpisa.inf file, and then click Install on the menu that appears.
3- Restart your computer.
Source: https://smallvoid.com/article/winnt4-plug-and-play.html
USB driver for Windows NT4: https://smallvoid.com/article/winnt4-usb-driver.html
@SomeGuy I get it, so I better try Windows 95 or 98.
Can anyone explain...??
it says this:
Microsoft Windows NT 4.0 Embedded (4.00.1381.204).7z Failed - Virus detected
From
https://winworldpc.com
Yes. I can. In fact, exercise a little critical thinking, and you can explain yourself. The comment immediately before yours gives the all important clue. Then, if you actually LOOK at the archive, you will see the ISO is dated from 2014.
And then you might ask yourself: "hmm is it reasonable to expect, that a file that has been archived for 11 years only now should be infected, and that I am the first to be aware of that?"
QEMU, Virtualbox & VMWare Workstation are hypervisors, in some cases they don't emulate most of the hardware (I'll explain this below), instead they act as a bridge between the VM and the system hardware. In a hypervisor the guest sees the host CPU and its possible to pass through physical devices like GPUs, USB devices, sound cards etc etc through to the guest. The host intercepts the hardware calls made by the guest, processes them and sends them back in the correct format (and given that modern CPUs still have 99.9% support for the OG 8086 CPU spec, not much processing is required)
They absolutely can emulate when needed, for example when you install NT4 on VMWare, it wouldn't be much good to pass it a modern NIC so it emulates a PCNET instead. The same is true for motherboard specs too, most hypervisors will emulate the base platform for older OSes, this is necessary for the same reason, passing NT4 a modern NVMe HDD controller is pointless.
In principle though, and as long as you are using an OS newer than the Q35 spec, the VM will be using the system resources as though it was running on the machine. This is why its still necessary to patch Windows 9x to run on hypervisors, modern CPUs are so fast they outpace the timers on OSes that old and the OSes really don't like it when the IRQ bus is running at 100000x what it should be, just for one example.
A metal hypervisor is simply a machine that is running a hypervisor as its OS, Vmware Sphere, Proxmox etc etc. These have one major advantage over a "software" hypervisor, if the OS is a hypervisor it can boot itself up using the bare minimum system resources and hold the rest of the hardware off the bus so you can carve it up between the guests with much more accuracy and control. If you've ever tried to get QEMU to pass your GPU to a Windows VM under Linux, you know the struggles with all the scripts you need to stop the card, remove it from the bus and pass it through so the OS can use it, metal hypervisors solve this by never initialising the card at all until the VM needs it, no scripting needed.
Hope this clears up the difference.