Re: [Freedos-kernel] prinf changes
2009/7/18 Kenneth J. Davis :
> 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
Re: [Freedos-kernel] prinf changes
On Sat, Jul 18, 2009 at 10:37 AM, Bart Oldeman 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] Fwd: FreeDOS kernel Build Fixed: Build 2009.07.18.001
2009/7/18 Kenneth J. Davis : > I was just checking my email and about to work on an issue with the > usb stack from Bret Johnson. Does this change effect/fix the issues > with this (from the description it looks like it does - as the problem > was described as FAT32 specific issue with the kernel and related to > the buildbpb call) or is it just something you ran across? Yes, see my post at http://bretjohnson.us/forum/ for details. My patch just changing the ISFAT32(dpbp) check to checking the corresponding field in the BPB (that bpb_to_dpb copies there). 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
[Freedos-kernel] Fwd: FreeDOS kernel Build Fixed: Build 2009.07.18.001
I was just checking my email and about to work on an issue with the usb stack from Bret Johnson. Does this change effect/fix the issues with this (from the description it looks like it does - as the problem was described as FAT32 specific issue with the kernel and related to the buildbpb call) or is it just something you ran across? -- Forwarded message -- BUILD SUCCESSFUL Project: FreeDOS kernel Date of build: 2009-07-18 11:03:55 Running time: 00:03:23 Integration Request: continuous triggered a build (IfModificationExists) Last changed: 2009-07-18 10:05:26 Modifications since last build (1) Modifiedbartoldeman/kernel/trunk/kernel/fatfs.cCheck the BPB instead of the DPB for FAT32 after a BUILDBPB device call, as the DPB may still be uninitialized at this point. 2009-07-18 10:05:26 Thank you, 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
[Freedos-kernel] prinf changes
Jeremy,
I was wondering what your reasoning is for changing
int VA_CDECL printf(const char *fmt, ...)
to
int VA_CDECL printf(CONST char FAR *fmt, ...)
are there any format strings that need to be far? Because for just
printing a far string s it's better to use
printf("%S", s);
because printf(s) goes all wrong if there are % signs in s. Moreover,
far strings are more expensive, both for all printf callers and printf
itself, and the prototype no longer matches what DOS compilers use
themselves.
CONST vs. const is probably a stylistic issue -- I guess CONST is only
in the kernel because Pat used pre-ANSI compilers a long time ago
without "const".
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
