I’m really surprised it didn’t “just work” under OS/2. I tried to compile it under DOS, and even cranking up conventional memory as high as possible, I couldn’t get one file to compile with optimization. It still generated an executable with one module not optimized, but I thought all the people developing it must have not had the same memory limit. Maybe the developer environment and the build farm were different.
The reason for P-Code is because real mode systems didn’t have memory paging. The P-Code system at the time did two things: a) generated much more compact code and b) allowed code to leave memory so that there was space for data. That system was used in pretty much all Microsoft products into the early 90s.
For PM Word, it used an early version of WLO, or Windows Libraries for OS/2. This meant Windows calls were translated to OS/2 via shim DLLs. In the “final” version of WLO, a program was a specially marked 16 bit Windows executable, so the same binary worked under Windows and OS/2 without modification. Unfortunately Word and Excel used prerelease versions which weren’t quite that polished. Also, WLO was abandoned after Windows 3.0, and the 3.0 API was just too limited, so it wasn’t really a viable way to write an OS/2 program.
To get Word for Windows 1.x to run on 32 bit Windows 10, you need to upgrade the resources to version 3.0 - the code to load 2.x icons was removed in very early NT releases.