IIRC, the accurate statement is that Win95 wasn't pure 32-bit.
In Win9x/Me, the core of the OS (the VMM) is 32-bit (which was true even in Windows 3.x in 386 Enhanced mode.) But, some other parts of the OS remained 16-bit code, and 32-bit apps will sometimes end up invoking 16-bit code via thunks when calling OS APIs.
By contrast, NT-based Windows, a 32-bit app will never invoke any 16-bit code. The only scenario in which 16-bit code would ever run would be when running a legacy 16-bit app.
(Someone please correct me if I'm remembering this wrong.)
Hm, if you were using 32bit applications and 32bit drivers then you wouldn't touch 16bit code (unless of course you did so explicitly).
However there were commonly used built-in dos utilities that were 16bit so if you called out to any of those then obviously you would invoke 16bit code.
One other difference: on Win9x/Me, it was possible for a 32-bit process to load a 16-bit DLL. It was a bit convoluted, in that you needed to create a 32-bit companion DLL which mediated between the 32-bit process and the 16-bit DLL, but it was supported – known as "flat thunking".
By contrast, Windows NT doesn't support 32-bit processes loading 16-bit DLLs, although it does support the reverse (16-bit processes loading 32-bit DLLs – "general thunking")
I'm not sure how widely this facility, of loading 16-bit DLLs into 32-bit processes, was used. I thought, Microsoft actually used it internally in implementing parts of Win95, but I could be misremembering that.
In Win9x/Me, the core of the OS (the VMM) is 32-bit (which was true even in Windows 3.x in 386 Enhanced mode.) But, some other parts of the OS remained 16-bit code, and 32-bit apps will sometimes end up invoking 16-bit code via thunks when calling OS APIs.
By contrast, NT-based Windows, a 32-bit app will never invoke any 16-bit code. The only scenario in which 16-bit code would ever run would be when running a legacy 16-bit app.
(Someone please correct me if I'm remembering this wrong.)