In theory, yes, it’s doable, provided that ‘any PC’ ignores systems running versions of Windows from before Windows NT 3.1, those running Windows RT, those using S Mode, and possibly specialized device-specific versions (and of course anything running something other than Windows).
The Win32 API is probably one of the most extreme cases of backwards compatibility in software that exists today. With the exception of some internal implementation details that will not matter to a vast majority of applications, the original API as provided by the first public release of Windows NT 3.1 on 1993-07-27 is still present and essentially unmodified in the latest versions of Windows 11. Anything using only those parts of the API will, if built correctly, run just as well on a system running the original Windows NT 3.1 as it will on a system running Windows 11. The same largely applies for newer versions of the API as well. Essentially every part of the Win32 API that was in NT 4 still works on Windows 11, as does essentially every part that was in Windows 2000, and XP, and Vista, and 7, etc.
As far as hardware, that’s also covered by the OS. Since about Windows NT 4.0 and Windows 98, ‘special’ APIs for specific implementations of a particular type of hardware are generally not a thing on Windows. Back in the days of DOS, or even Windows 1.0 or 2.0, you would indeed often find programs that would talk directly to the driver or even the hardware itself. But it’s long-since been the case that to use an audio device, you talk to the OS itself, which provides an API that abstracts all the standard audio device functionality, and thus you have one consistent interface you use for all audio devices¹.
There are three big caveats to this however:
- It’s not exactly trivial to program to just the Win32 API. It’s technically doable in this case since the stated app is so absurdly simple, but the Win32 API, and especially the old parts, is quite simply kind of a pain in the arse to work with and not very well designed. It’s also very easy to unintentionally use newer parts of the API unless you really know what you’re doing. Given this, you should be asking for a demo of this program and testing appropriately, and then assuming that it may break in subtle ways that nobody could predict years down the line.
- Microsoft themselves are not actually that happy with the Win32 API, and have been slowly pushing on and off to force people over to their new UWP APIs since the release of Windows 8. It’s extremely unlikely that they will actually completely remove any time soon (I would put better odds on Windows being officially ported to RISC-V before the Win32 API is removed from Windows), but this is something to keep in mind.
- While Windows on ARM technically supports x86 Win32 applications, there is a distinct possibility that there may be problems for such applications on Windows on ARM if they need to do real-time data processing (which is arguably needed for a useful audio recorder or player). There’s theoretically an impending shift to ARM as a primary platform for consumer PC hardware on horizon², so this may be worth keeping in mind.
1: Interestingly, the same is actually also true for much of the hardware interface for essentially all internal audio devices in computers that are not add-in cards. Older systems almost exclusively used AC'97 hardware, while new ones use Intel’s HD Audio interface, even for the audio output via HDMI/DP on graphics cards.
2: Given the rather heated disagreement between Qualcomm and ARM Holdings right now, it’s uncertain whether this shift will actually be happening any time soon, but it is still worth keeping in mind since it’s already happening to some extent in workstation systems, and the shift there is being driven by companies other than Qualcomm.
