OSDev.org

Hobbes wrote:Smeezekitty apparently doesn't care about scalability or portability, but IMHO that's exactly the point of this topic.

There's a crucial difference between being aware of an issue and ignoring it, or being unaware of an issue.

He said he's using "unsigned long", and that's 100% OK with me. But "because I am in real mode" isn't the right kind of reason for such a decision, and "so in 16bit you use long to get 32 bits" is dangerous advice.

Then again, is there a single C compiler in the world that produces 16 bits real mode code and does not define long as 32 bits?

I do know one that does not define int as 16 bits...

Combuster wrote:I do know one that does not define int as 16 bits...

Really? Which one is that?

You're probably using it: GCC

(and please, google .code16gcc before attempting to fail )

GCC doesn't produce 16 bits real mode code, does it?

Too late with the edit

But you still failed.

Last time I looked, there was some experimental, somewhat unreliable, not officially supported way to make GCC produce "pure" 16bit code mentioned in the GNU 'as' documentation (.code16gcc), but certainly nothing I would use outside the GCC maintenance team.

Combuster,
Ah no, GCC still produces 32 bits code. The .code16gcc directive just tells GAS to add a32/o32 prefixes so it may run in 16 bits mode.

Solar,
D.J. Delorie did something like that: http://www.delorie.com/djgpp/16bit/gcc/.

@Solar, Counter-question: What's better supported: Turbo C++ 1.0 or .code16gcc?

Ah no, GCC still produces 32 bits code.

Ah the red herring. GCC emits binaries which run in 16 bit mode.