I'm pretty sure that excuse is random bullshit. First, are handles limited to 16 bits in 32-bits Windows? I'm pretty sure they are not, especially when the 2 l

I'm pretty sure that excuse is random bullshit. First, are handles limited to 16 bits in 32-bits Windows? I'm pretty sure they are not, especially when the 2 lsb are 0 for NT handles... Second, you could cherry-pick other random resource pointer and make up another excuse with the same power: e.g. "32-bits programs can not work under 64-bits Windows because pointers are 64-bits wide with 'all' (at least > 32) their bits used, so they won't fit in 32-bits pointers of 32-bits programs" That's not how retro-compatibility involving virtualization is engineered - that's pretty much the other way around! If MS wanted to make Win16 run on 64-bits Windows, they could have engineered it (without much difficulty). They choose not to (and I don't blame them too much for that) and as a result, maybe some (or a lot) of details that would have been needed to ease that implementation do not exist (maybe SOME handles were limited to 16-bits on 32-bits Windows, all the time or when the program was a 16-bits one - and the provision to limit to 16-bits is not there anymore in 64-bits Windows as a result of the lack of purpose it would have given the general lack of support of win16 on this plateform), which maybe makes it harder to do for a 3rd party now... (and even by MS, given Windows has evolved a lot since introduction of 64-bits)