Actually, *both* Turbo and Borland C didn't like it!This is strange. The old code has been there for ages even when we compiled with Turbo C by default.
Yes, but the bug didn't reveal until MENUCOLOR and the 8-bit strings it allows were introduced. By that time the default compiler was switched to OpenWatcom so the bug never had the chance to show :(
I see:
0010 B8 00 0E mov ax,0x0e00 0013 0B 46 04 or ax,0x4[bp]
Borland C translates this code to: mov si,0x4[bp] [...];code that doesn't alter si mov ax,0x0e00 or ax,si which is equivalent.
which should be correct since the high byte should be 0.
Yes, it SHOULD, but it is NOT! An alternative would be to change the type of c from int to char but this would deviate from the good old K&R standard that the putc() function accepts int ;-)
Ahh. Some calls to put_console most likely sign extend the byte then. That should be corrected as well then.
EXACTLY! Now I see that put_unsigned() and put_string in prf.obj have a CBW instruction that does just that! So, what do you suggest? I think that we can just apologise to K&R and change c in put_console() to char.
Thanks! -- I'll have a closer look since I remember similar issues.
OK. A "peer review" is always welcome :)
Lucho
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
