2009/7/20 <ibid...@lavabit.com>: > Jeremy: > The FAR printf is probably good for 16-bit builds with DEBUG defined. > However, there are at least two potential issues (NOT YET VERIFIED). > 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past > 4GB. I don't know how the compilers treat FAR in these builds. > 2.Low memory systems? > It might be good (though perhaps difficult) to > 1 Check for 16-bit > 2 Check for DEBUG > If both are true, > 3 Use FAR printf
with my commit printf only now uses FAR pointers for DEBUG statements in resident code, but just to clarify: the "386" builds don't use 32-bit code segments with 32/48-bit pointers, DPMI, etc, they only tell the compiler that it is allowed to use CPU instructions that are only available on 386+ processors, such as movsx, movzx, and those involving fs and gs segments. Some compilers use 32-bit registers for (unsigned) longs. But It all remains real mode code with 16-bit segments. The *only real* advantage of the 386 builds is that the code size decreases so kernel.sys and its resident memory footprint decrease; theoretically it could be a bit faster too but I'd be surprised if anyone could measure that. Bart ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
