16bit code generation

[Ben Klein]

2009/3/22 James McKenzie <jjmckenzie51 at earthlink.net>:
> Ben Klein wrote:
>> Oops, missed reply-to-all.
>>
>> 2009/3/22 Tijl Coosemans <tijl at ulyssis.org>:
>>
>>> I was reading through binutils documentation and came across this.
>>> Maybe it can be used to compile 16 bit tests.
>>>
>>> 3.2.4. 16-bit mode
>>> Binutils (2.9.1.0.25+) now fully support 16-bit mode (registers and
>>> addressing) on i386 PCs. Use .code16 and .code32 to switch between
>>> assembly modes.
>>>
>>> Also, a neat trick used by several people (including the oskit authors)
>>> is to force GCC to produce code for 16-bit real mode, using an inline
>>> assembly statement asm(".code16\n"). GCC will still emit only 32-bit
>>> addressing modes, but GAS will insert proper 32-bit prefixes for them.
>>>
>>
>> 16bit mode is required for building bootloaders. The question here is,
>> is it possible for Wine to run raw 16bit code when running under a
>> *nix kernel, which typically (always?) run in protected mode? I
>> believe it is not possible without some sort of 16bit emulator/wrapper
>> (e.g., current win16 libs are actually compiled as 32bit).
>>
>>
> Actually, the modern versions of Windows (Windows95 and up) use 16 to 32
> bit 'thunking' which is time consuming and not pretty.  It would be nice
> to get some of the legacy 16 bit applications running under Wine, but
> this will require a great deal of work and may not be worth the effort.
> This being said, there is always the one user that has a legacy
> application which they must have.

Well, I know *some* win16 stuff runs in Wine (not that I've tested it
for a while), and I know that every desktop Windows version up to at
least WinME has 16bit components built in (16bit interprocess
messaging, from what I recall), but I thought WinNT, Win2k, WinXP etc
had no 16bit internals, and that 16bit apps only ran in some form of
VM or emulator (e.g. the DOS emulation supported by cmd.exe in
Win2K/XP).