Executable files for 16-bit Windows are usually laid out in the now-rather-inaccurately-named New Executable format. Most current Windows executable analysis tools do not support this format; they can only read files in the 32-bit and 64-bit Portable Executable format. This is what the error message you cited is trying to tell you.
As for how to extract assets from the game, that will depend on how they are stored.
- The crudest way to find embedded data would be to use a tool such as binwalk, which can scan for signatures of common data formats and extract data that follows. In my own test on NE executables bundled with Windows itself, the results of using this tool were rather underwhelming; I guess that it is likewise tuned for looking for modern formats rather than historically-used ones, which have rather few distinguishing features anyway. But it may be an option worth at least trying.
- Since the asker mentioned it’s a Windows 3.x game, the assets may be embedded in the executable as Windows resources. Those can be extracted and manipulated with tools analogous to modern resource editors, but with support for NE files. Such were often distributed with contemporaneous compiler toolchains:
- Borland Resource Workshop, itself a 16-bit Windows program, distributed with later versions of Borland’s early Pascal (Turbo/Borland Pascal 7) and C++ (Borland C++ 3.1) toolchains;
- The Watcom Resource Editor, distributed with the Watcom/OpenWatcom toolchain (I am much less familiar with it, and so I am less sure whether it actually supports reading complete executables).
- The assets may be simply static data embedded in the executable image next to the code. In that case, finding and extracting it will require using a disassembler such as Ghidra. Disassembly is a laborious process that requires knowledge of assembly language and some skills in its own right, but in the long term it’s the only one guaranteed to produce definitive answers as to where the executable actually looks for data.
Though most of the above is assuming that the data are actually embedded directly (and uncompressed, too) in the executable file itself, which it need not actually be. You may need to scan other game files if there are any, or failing that, again, disassemble the executable and learn where it looks for the assets.