Re: [Freedos-kernel] prinf changes

2009-07-18 Thread Kenneth J. Davis
On Sat, Jul 18, 2009 at 10:37 AM, Bart
Oldemanbartolde...@users.sourceforge.net wrote:
 Jeremy,

 I was wondering what your reasoning is for changing

It has to deal with debugging the kernel, especially during
initialization.  I choose this method as the kernel does not usually
have many strings it prints except when built with DEBUG and the
alternative is to determine exactly which portions of the C code and
corresponding strings may possibly reside in different segments at
different times (any time DS may not equal seg of string) and change
just those prints - otherwise some strings print and some print
garbage.  I realize it changes printf prototype to only match
compilers in large data mode, but the kernel does not use printf from
the standard library of DOS compilers anyway.  However, I will revert
the changes if you prefer.

Yes the CONST const issue is just trying to keep the code consistent
since CONST is the preexisting usage.

Jeremy

--
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


Re: [Freedos-kernel] prinf changes

2009-07-18 Thread Bart Oldeman
2009/7/18 Kenneth J. Davis jere...@fdos.org:
 It has to deal with debugging the kernel, especially during
 initialization.  I choose this method as the kernel does not usually
 have many strings it prints except when built with DEBUG and the
 alternative is to determine exactly which portions of the C code and
 corresponding strings may possibly reside in different segments at
 different times (any time DS may not equal seg of string) and change
 just those prints - otherwise some strings print and some print
 garbage.  I realize it changes printf prototype to only match
 compilers in large data mode, but the kernel does not use printf from
 the standard library of DOS compilers anyway.  However, I will revert
 the changes if you prefer.

ok, I've reverted some of the changes: I found a couple of situations:

DS == SS == DGROUP: this is normal, no problems here.

DS == DGROUP, but SS!=DS. This happens for instance in nls.c, in that
case we need to be careful by making pointers to items on the stack
FAR, and similarly for va_list/va_arg. I've kept that part of your
change, but only for resident debug printf()s. Compiling such code
with -zu helps for OW (especially also to catch warnings) but
unfortunately such a switch isn't there for TC, so we need to handle
this situation manually.

DS != DGROUP, and (perhaps) SS!=DS. This is very confusing and doesn't
even work after your change:
printf(foo) with a far format string is just compiled into a PUSH
DS/PUSH foo/CALL printf.
So we need to *always* keep DS equal to DGROUP in C code, which is why
I fixed the entry to the kernel's
int2f/ah=14 handler for NLSFUNC in nls.c.

By the way, I didn't find init code where SS!=DS, but did you find any?

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