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.
Oops, missed reply-to-all.
2009/3/22 Tijl Coosemans tijl@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).
Ben Klein wrote:
Oops, missed reply-to-all.
2009/3/22 Tijl Coosemans tijl@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.
James McKenzie
2009/3/22 James McKenzie jjmckenzie51@earthlink.net:
Ben Klein wrote:
Oops, missed reply-to-all.
2009/3/22 Tijl Coosemans tijl@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).
On Sat, Mar 21, 2009 at 8:28 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Ben Klein wrote:
Oops, missed reply-to-all.
2009/3/22 Tijl Coosemans tijl@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.
James McKenzie
Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw.
-- -Austin
On Sunday 22 March 2009 04:00:16 Austin English wrote:
Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw.
Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom. Now it seems gcc could be used (perhaps with some help from winegcc). There's more at http://sourceware.org/binutils/docs/as/i386_002d16bit.html
Am Sonntag, den 22.03.2009, 11:46 +0100 schrieb Tijl Coosemans:
On Sunday 22 March 2009 04:00:16 Austin English wrote:
Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16
Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom.
Yes. That's at least one reason.
Now it seems gcc could be used (perhaps with some help from winegcc).
No, gcc cannot be used. gcc is not able to compile x86 16-bit code, it's just as that can translate 16 bit assembler code.
Regards, Michael Karcher
On Sun, Mar 22, 2009 at 5:46 AM, Tijl Coosemans tijl@ulyssis.org wrote:
On Sunday 22 March 2009 04:00:16 Austin English wrote:
Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw.
Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom. Now it seems gcc could be used (perhaps with some help from winegcc). There's more at http://sourceware.org/binutils/docs/as/i386_002d16bit.html
What is wrong with OpenWatcom? It is an open source development toolchain, with experimental linux binaries, yes, but they do work the last time I checked (which was when 1.8 release came out).
On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha ngompa13@gmail.com wrote:
On Sun, Mar 22, 2009 at 5:46 AM, Tijl Coosemans tijl@ulyssis.org wrote:
On Sunday 22 March 2009 04:00:16 Austin English wrote:
Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw.
Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom. Now it seems gcc could be used (perhaps with some help from winegcc). There's more at http://sourceware.org/binutils/docs/as/i386_002d16bit.html
What is wrong with OpenWatcom? It is an open source development toolchain, with experimental linux binaries, yes, but they do work the last time I checked (which was when 1.8 release came out).
It's not widely available, it's license is not open enough for many distros (ArchLinux has it available, and there's an initial Gentoo ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it available.
It's also not known how well it works under Linux. There was talk about detecting if a user has it installed, then compiling 16 bit code in that case, but no one's worked to see if OpenWatcom works when ran/installed natively.
2009/3/28 Austin English austinenglish@gmail.com:
On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha ngompa13@gmail.com wrote:
What is wrong with OpenWatcom? It is an open source development toolchain, with experimental linux binaries, yes, but they do work the last time I checked (which was when 1.8 release came out).
It's not widely available, it's license is not open enough for many distros (ArchLinux has it available, and there's an initial Gentoo ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it available.
It fails DFSG (so I'm surprised it passed OSI, given OSI is based on DFSG), with many important concerns raised:
http://www.mail-archive.com/debian-legal@lists.debian.org/msg34684.html
I emailed licensing@fsf.org to ask about it (since it isn't on their list of licenses) and got back a quick reply saying an official determination wasn't likely any time in the foreseeable future, but it's definitely not GPL compatible and they couldn't actually tell at a glance if it was FSF "free" or not.
- d.
On Sun, Mar 29, 2009 at 6:12 PM, David Gerard dgerard@gmail.com wrote:
2009/3/28 Austin English austinenglish@gmail.com:
On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha ngompa13@gmail.com
wrote:
What is wrong with OpenWatcom? It is an open source development
toolchain,
with experimental linux binaries, yes, but they do work the last time I checked (which was when 1.8 release came out).
It's not widely available, it's license is not open enough for many distros (ArchLinux has it available, and there's an initial Gentoo ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it available.
It fails DFSG (so I'm surprised it passed OSI, given OSI is based on DFSG), with many important concerns raised:
http://www.mail-archive.com/debian-legal@lists.debian.org/msg34684.html
I emailed licensing@fsf.org to ask about it (since it isn't on their list of licenses) and got back a quick reply saying an official determination wasn't likely any time in the foreseeable future, but it's definitely not GPL compatible and they couldn't actually tell at a glance if it was FSF "free" or not.
- d.
Unfortunately, at the moment it really is the best we have. AFAIK, there isn't any other FOSS compiler that can build 16-bit DOS/Win16 applications. Unless someone was actually willing to figure out how to make GCC be able to target Win16 (not likely) or write a whole new compiler toolchain to target Win16/DOS, there really isn't anything else left to use.
On Sun, Mar 29, 2009 at 06:23:53PM -0500, King InuYasha wrote:
Unfortunately, at the moment it really is the best we have. AFAIK, there isn't any other FOSS compiler that can build 16-bit DOS/Win16 applications. Unless someone was actually willing to figure out how to make GCC be able to target Win16 (not likely) or write a whole new compiler toolchain to target Win16/DOS, there really isn't anything else left to use.
Will 'Bruce's C Compiler' target DOS/Win 16 ?
David
On Mon, Mar 30, 2009 at 2:47 PM, David Laight david@l8s.co.uk wrote:
On Sun, Mar 29, 2009 at 06:23:53PM -0500, King InuYasha wrote:
Unfortunately, at the moment it really is the best we have. AFAIK, there isn't any other FOSS compiler that can build 16-bit DOS/Win16
applications.
Unless someone was actually willing to figure out how to make GCC be able
to
target Win16 (not likely) or write a whole new compiler toolchain to
target
Win16/DOS, there really isn't anything else left to use.
Will 'Bruce's C Compiler' target DOS/Win 16 ?
David-- David Laight: david@l8s.co.uk
Well, I stand corrected, Bruce's C Compiler will target DOS, but it doesn't look like it targets Win16, since it targets only DOS COM executables, not the DOS NE executable type also required (NE type is the one used in Win16 which is different from DOS COM type).
On Sun, Mar 22, 2009 at 11:34:03AM +1100, Ben Klein wrote:
Oops, missed reply-to-all.
2009/3/22 Tijl Coosemans tijl@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.
I believe that does work and has been used by 'bochs' to compile bios code.
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).
NetBSD (at least) has VM86 support in the kernel, however I don't know if it still works :-)
David
-
Austin English -
Ben Klein -
David Gerard -
David Laight -
James McKenzie -
King InuYasha -
Michael Karcher -
Tijl Coosemans