Return to Answer

After doing a bit of research (on Raymond Chen's blog) one of the better examples of things Windows compilers did on 16 bit Windows was to increment BP before pushing it on the stack in a far called function (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit Windows and I remember Microsoft at the time period (things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler, probably not.

After doing a bit of research (on Raymond Chen's blog) one of the better examples of things Windows compilers did on 16 bit Windows was to increment BP before pushing it on the stack in a far called function (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://devblogs.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit Windows and I remember Microsoft at the time period (things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler, probably not.

After doing a bit of research (on Raymond Chen's blog) one of the better examples of things Windows compilers did on 16 bit Windows was to increment BP before making a far call (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit Windows and I remember Microsoft at the time period (things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler, probably not.

After doing a bit of research (on Raymond Chen's blog) one of the better examples of things Windows compilers did on 16 bit Windows was to increment BP before pushing it on the stack in a far called function (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit Windows and I remember Microsoft at the time period (things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler, probably not.

After doing a bit of research (on Raymond Chens blog) one of the better examples of things windows compilers did on 16 bit windows was to increment BP before making a far call (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit windows and I remember Microsoft at the time period (Things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler probably not.

After doing a bit of research (on Raymond Chen's blog) one of the better examples of things Windows compilers did on 16 bit Windows was to increment BP before making a far call (and decrementing it afterwards) so the code that walked the stack knew the size of the return address.

https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203/

Compilers did need to do some odd things to work with 16 bit Windows and I remember Microsoft at the time period (things got better during the OS/2 Windows 3.x era) being a bit of a pain to work with.

So unless you were writing assembler, probably not.