On Mon, 23 Aug 2004, Aitor Santamar�a Merino wrote:
> (1) why are there STRINGS.C and MISC.C, apparently with the same
> functionality and same routines in the same programming language?
They are just there for reference now. You have to go back to the last
kernel released by Pat to understand.
here I see:
asmsupt.asm has bcopy, fbcopy
misc.c has scopy, fscopy, fsncopy, bcopy, fbcopy, skipwh, scan, isnum,
GetNumber, scan_seperator.
strings.c has strlen, fstrlen, strcpy, _fstrcpy, strncpy, strcat, strcmp,
fstrcmp, strncmp, fstrncmp, fstrncpy, tolower, toupper.
At some point Tom and I decided to get rid of scopy and bcopy in
favour of strcpy and memcpy (bcopy is a non-standard 4.3BSD style
function, it does the same as memcpy with arguments reversed).
Also, as we all know, Tom is a big fan of assembly language but only
when he thinks it is appropriate ;) So he implemented these functions in
asmsupt.asm. Now we don't use misc.c and strings.c any more. They're just
there in case somebody wants to play with M68K's or whatever.
> (2) I observe that the standard block device and the standard clock$
> device initialisation routines are not included as the initialisation
> call of the corresponding procedures, but that have been included as
> sepparate routines, called separatedly. I observe that they are called
> AFTER all the other devices have been initialised, a PSP is set to
> "current process" and LastDrive is stablished. I can understand that the
> later two stuff could be necessary (at a first glance) for the
> initialisation of the disks, but why for the clock?
> Otherwise, couldn't the order be:
> - set a PSP to current process
> - set a lastdrive
> - initialise all drivers (including disk, clock$) within their INIT routines
> The only thing I can come up with is that they are C routines, and are
> called from inside a C routine.... is this right?
> Along the same lines, Serial ports and printers are initialised in C
> routines inside MAIN.C (routines that seem to have straightforward
> assembly form), couldn't these be part of the init of COMx and LPTx
> (thus avoiding, for example, the loop)?
Basically device driver init happens before DOS is active, it's the nature
of low level init.
lastdrive and PSP are DOS level things, device drivers have to go first.
In fact the lastdrive value depends on the number of drives that initdisk
finds.
The reason for having the device driver init in C is to have it in the
init text segment (we get rid of it after init) instead of in the device
driver segment. The
do {
init_device(device, NULL, 0, &lpTop);
device = device->dh_next;
}
while (FP_OFF(device) != 0xffff);
loop is the proper way to init all drivers. But as it is impossible to let
the drivers' init (near) function pointer point into (far) init code we
call these guys seperately and manually.
> (3) I see that the BPBs are initialised (MAIN.C:InitializeAllBPBs) by
> opening and closing a file for each drive, any hint why this is so?
> (such as code in DSK.C where I could see: "if file opened for the first
> time, then initialise the BPB").
This is a bit of a hack, it really needs to be a nicer function but at the
time this was the easiest way to solve the problem with Norton :)
It's not only about bpb init (part of dsk.c) but also dpb init (done by
bpb_to_dpb in fatfs.c.
> (4) I ignore if the boot loader will send any valuable value to kernel
> routine inside variables AX and BX. Nevertheless, the following code
> seems to show that the value of AX is lost (and I ignore if the value on
> BX is useful), so I'd suggest this small change. Correct?
BX is used to store the boot drive in BL (see boot.asm). But you're right
about AX. It doesn't need to be pushed and popped.
> (5) By the way, strangely enough I don't happen to see "123 - Initdisk"
> anymore, due most probably to the \r before the kernel compatibility.
> Now I was just wondering who prints "FreeDOS kernel version 1.1.35
> (Build 2035) [May 30 2004 22:09:36]?
Yes, it's the \r. It's there for troubleshooting so if the kernel hangs
after 12 you see that. signon() in main.c prints the message.
> (7) A big questions: I have noticed the following two things:
> - there is a stack for the IRQ interrupts (apparently independent from
> the rest)
> - there is a kernel stack
> I have noticed stack switching back and forth on the entry/exit points
> to FreeDOS (int 2x, for example)
> However, I have often read about the "multiple kernel stacks", I don't
> know if this refers to these two, and second, I completely ignore the
> use of the STACKS= switch (should this be related), can someone clarify
> a bit on this please?
STACKS= are irqstacks, they are used for hardware interrupts.
For DOS stacks (which DOS uses for int2x) we have a few, these are the
"multiple kernel stacks"."Undocumented DOS" tells about them. There's the
character, disk i/o and error stack. Essentially if you're on the
character stack (determined by AH) you can re-enter DOS on the disk
stack, if DOS isn't "busy". This is for programs that hook int29 (THELP
for Turbo Pascal is one of these).
The error stack is for critical error handlers so they can call DOS to
display the "Retry, Abort, ..." message and ask for keyboard input.
> (8) At the end of PreConfig one can see the following comments about MCB
> initialisation, whereas it has obviously been moved to PreConfig2. I'd
> suggest this cosmetic change (or remove any comment at all), am I correct?:
> =====
> - /* Done. Now initialize the MCB structure */
> - /* This next line is 8086 and 80x86 real mode specific */
> + /* MCB initialisation was once here, now moved to PreConfig2 */
> #ifdef DEBUG
> printf("Preliminary allocation completed: top at %p\n", lpTop);
> #endif
> }
> =====
Yes, the comment is obsolete.
> (9) Finally, after the comments and patches by Lucho, I sincerely
> expected to see some kind of LOOP in the MAIN.C:kernel() function, as I
> see none, I guess I am misunderstanding this, so how does this work
> whenever one exists the main SHELL?
The loop is in resident code, otherwise it would disappear. task.c:P_0().
Bart
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
