Re: [Freedos-kernel] new conv mem highs.
The patched kernel behaves very strangely! :-( It outputs an error for DEVICE=C:\DOS\HIRAM.EXE line and doesn't load it and repeates this with many other lines (but not all). For my simpler floppy configuration, it doesn't load HIMEM64.EXE without even showing an error! The current nightly-kernel may have reached a new landmark in the quest for smaller conventinal-memory footprint but it lost ground in usability and compatibility. My test-machines halt on various arbitrary points telling me: more than two near fnodes requested at the same time Can you check again? I think I solved at least Lucho's problem during the init phase -- when fnodes could overlap disk buffers! Weird things could happen indeed. After booting I haven't seen the message you quote though, so please let me know how to reproduce if it still occurs for you. I made an intermediate kernel tarball just in case the cronjob fails. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] VDISK header
Also, where documented VDISK header (where I may read about this)? BO It's in the VCPI spec. Available at many places including here: BO www.dose.se/docs/osdoc/unsorted/ProtectedMode/VCPI.txt No, there sayed only about signature and showed how to copy word value from offset 0x1E. :( Other fields are unexplained. it's a boot block. The rest (for a real VDISK) will be a normal BPB (pre DOS 3.0 so no hidden sectors DWORD). I am too tired now to answer the other questions :) Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] root entries field
On Tue, 23 Mar 2004, Arkady V.Belousov wrote: Bart, let me remind me %subject% issue: why FD returns nonzero field for FAT32 in (and only in) current BPB? most likely because of dsk.c: pbpbarray-bpb_ndirent = 512; Why that line is there? I don't know. It was already in the first FAT32 kernel from Victor Vlasenko so he's the one who put it in. I think this line can be removed. For the default bpb it's correctly set to 0 in initdisk.c Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
On Mon, 22 Mar 2004, Eric Auer wrote: Hi, about add_far() pointer normalization: I think it would be better to normalize earlier. If you have a pointer, you normally have a pointer to a STRUCTURE. If the end of the structure ends up with an offset 0x then having the POINTER normalized is not enough. So how do you check the SIZE of the structure for which you normalize the pointer? Or do you just have an hardcoded constant maximum structure size for structures for which the add_far function can be used? add_far is only used at a few select places where we want to have the offset part as low as possible. Nothing to do with structures but everything to do with potentially large file reads, with read chunk, update pointer loops. Quite possibly Arkady's approach minimizing normalizations has merit but then each add_far caller needs to be checked if it needs to manually normalize the pointer afterwards. But for now, because it's not called very often, the time it takes is very small in comparison with the BIOS calls following, and normalization doesn't hurt, I haven't changed it. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Last change introduced an unknown unit delete bug
On Mon, 22 Mar 2004, Luchezar Georgiev wrote: :\elv_3e5.1 I mean i:\elv_3e5.1 Sorry for my typo! should be fixed now. remove_lfn_entries() calls dir_read with the offset == -1 which is not possible for normal directories (. and ..) but is possible for root directories. So the 65535 check only needs to be applied to non-root directories; the real limit for root directories is checked somewhere further down the line. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Last change introduced an unknown unit bug
On Mon, 22 Mar 2004, Luchezar Georgiev wrote: But what if it was the first entry in the root directory? Then the new_diroff++ in dir_read() will make it -1! remove_lfn_entries() checks for fnp-f_diroff == 0. The first entry can't have any LFN entries connected to it. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
On Mon, 22 Mar 2004, tom ehlert wrote: AVB (BTW, is protection AVB from wrapping HMA pointer into IVT by replacing wrapping into start of HMA AVB worth of code?) a working kernel is worth a lot of code (even if you don't see the reason immediately) HANDS OFF THE KERNEL, please. in the end it was just easier to remove add_far() and use buffer = adjust_far(buffer + offset). The only users are dsk.c and fatfs.c, where this is safe as long as you normalize the pointer before the loop. Which it was in fatfs.c but not in dsk.c. For the HMA. Yes, hands off: we do often read things (indirectly) into the HMA, there are BUFFERs there for instance. Maybe, just maybe, we're safe now with removing HMA logic from adjust_far() -- but it's way too easy to break this and will lead to bugs that are hard to solve. The current CVS kernel now has a 450 bytes smaller HMA_TEXT than ke2033 :) Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] redirection BUG
That's strange. Then MS-DOS DEBUG would also leak handles... the difference is that msdos debug calls int21/ah=26 instead of 55. Here's a kernel bug inspired by the RBIL comment this function is implemented using the same code as AH=26h taken too literally... Reality is that the only things that ah=26h should do is to copy the PSP (from CS, not the cu_psp value) set int22,23,24 and set parent PSP to 0. ah=55 does a lot more. Well this will take a little longer to fix so I'll do that later. It does mean however that FD debug will need to call ah=26 and not ah=55 to avoid leaking handles. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: ZIP media change not detected bug fix
On Wed, 17 Mar 2004, Luchezar Georgiev wrote: The patch below should fix the ZIP media change not detected bug, *if* my assumption about ZIP driver setting both DF_FIXED and DF_CHANGELINE is right. Never hurts to assume that this MAY happen though... If the ZIP drive has its own device driver (with DEVICE=) than whatever is in floppy.asm has no influence. Or is it really handled via the BIOS as drive A: or drive C:? In any case a change to init_readdasd in initdisk.c (+ your change in dsk.c) may be more appropriate than floppy.asm since the changeline status of a drive won't change after booting -- and I don't think DOS is advanced enough to handle hotplugging between non-changeline and changeline floppy drives... Bart --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BC/TC comment, root dot find bug fix patch
On Sun, 7 Mar 2004, Luchezar Georgiev wrote:
The following log comment is slightly incorrect:
prf.c
Log Message:
Borland C (unlike Turbo C) didn't like this pseudo register use.
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. I see:
0010B8 00 0E mov ax,0x0e00
00130B 46 04 orax,0x4[bp]
which should be correct since the high byte should be 0.
Ahh. Some calls to put_console most likely sign extend the byte then. That
should be corrected as well then. Anyway the new code is one byte smaller.
After some fiddling with debug kernels and the very old (1987!) but
excellent STEPDOS Int 21 tracer (http://www.chiphead.de/pages/stdos.htm),
I come up the following patch which fixes the bug.
--- cvs/kernel/kernel/dosnames.c 2003-06-15 20:57:02.0 +0200
+++ src/kernel/kernel/dosnames.c 2004-03-07 14:02:30.0 +0200
@@ -113,6 +113,8 @@
{
if (*filename != '\0')
return DE_FILENOTFND;
+ if (nDirCnt = 3) /* D:\ (D=drive) */
+return DE_NFILES; /* root has no '.' */
memset(fcbname, '?', FNAME_SIZE + FEXT_SIZE);
return nDirCnt;
}
Thanks! -- I'll have a closer look since I remember similar issues.
Bart
---
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=1470alloc_id=3638op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BC/TC comment, root dot find bug fix patch
On Sun, 7 Mar 2004, Luchezar Georgiev wrote: 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 KR and change c in put_console() to char. or cast to unsigned char. That's standard practice just like for is* functions. Well the idea of this is that getchar() returns int() so you would keep a single character read from a file in an int. With a special value being EOF (usually -1, but just has to be negative in general). In our case put_console can just as well take unsigned char since it doesn't deal with EOF. Brt --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel stacks
On Wed, 3 Mar 2004, Luchezar Georgiev wrote: On Tue, 2 Mar 2004 21:06:03 + (GMT), Bart Oldeman wrote: at first sight it looks good to me, thanks! The one thing I saw that might have to be changed is the location of the new stack. Since RBIL table 1690 (very end of interrupt.g) specifies a few variables up to 7d? and this new stack should certainly not be part of the swappable data area. I now look at this table and I now see why the stack size was selected as 384 bytes! I wonder if these words are too MS-DOS internal use only and whether we should care about them. Yes we should care! This area is used by all sorts of TSRs and network redirectors that live under DOS. These fixed locations cannot be changed without breaking apps that rely on undocumented DOS in various ways. One possible solution would be to decrease the stack size to 288 bytes (120h) - then the four stacks could fit. theoretical perhaps Have a look at the stacks after DOS has booted to see how much is left (you can see the high water mark by watching 90 90 ...) -- 288 bytes is really not a lot and Tom and I have had to go through some real trouble in the past to reduce stack usage. I don't know. I'd like to ask you to write a description of the kernel stack usage, Most is described in books such as Undocumented DOS. They describe the disk_api (int21/ah0ch), char_api (int21/ah=0ch) and error stacks (for int24) that we have too. On top of that FreeDOS has private stacks for the builtin clock (sysclk.c) and block (dsk.c) device drivers. Of all these stacks need to be in the swappable data area, since if a SDA-swapping TSR decides to reenter DOS it will need to restore the stacks after finishing. Some TSRs such as THELP however are called from int28 where DOS uses the char_api stack. So THELP is free to call any DOS function on the disk_api stack. However the new stack you now have put in is not affected by any re-entering so can stay out of the SDA. and how the STACKS configuration parameter affects it. Not at all. STACKS affects the (dynamically allocated) IRQ stacks used by hardware interrupts (ints 8-f and 70-77) STACKS=0,0 causes 0 IRQ stacks -- a side effect could be that the DOS stacks (or application stacks) could overflow then. Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] INT25
On Mon, 1 Mar 2004, Arkady V.Belousov wrote: __O\_/_\_/O__ int absread(int DosDrive, int nsects, int foo, void *diskReadPacket); #pragma aux absread = \ int 0x25 \ sbb ax, ax\ parm [ax] [cx] [dx] [bx] \ modify [si di bp] \ value [ax]; _ O/~\ /~\O Isn't there should be added POPF after INT 25h/26h? there should indeed be. In the current sys it simply happens to work since the int 25/26 is followed by mov sp, bp. Strange that in your example the pragma doesn't seem to preserve bp however ... FreeDOS preserves it, don't no about others.. I don't think dx= is a problem for floppies / 32MB for any DOS = 3.31. But I'm not a 100% sure; I know for sure that people have used sys successfully from DOS 6.22 Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
Following this discussion I looked at when and why I removed the code we're talking about from HMA_TEXT. It's not as easy as a mere code save. It goes all the way back to kernel 2024a released Apr 16 2001. Before that kernel there was a p_0() function in task.c. Around that time we were making huge gains in the memory usage of the kernel. First Tom implemented HMA support (before that the resident part of the kernel was in a fixed location in low memory). At that point the init code was already seperated from the rest, but the init data was not. First Tom implemented claiminit which meant that the data segment for the init code was still the same as for the resident code but was later claimed back. This was however quite tricky because the init code itself allocates memory and you'd easily create a hole that way. So the next step was to give the init code its own data segment and stack. Easiest way was to run the init code in the tiny model. This however meant that p_0() could no longer be in task.c. Problem is: which stack should p_0() use? Not the init stack, as it is overwritten. Also none of the three kernel stacks. These can be used by any DOS call. And I decided it was not worth the effort to create another stack just for p_0... It can be done though (look at ker2023e.zip from ibiblio): * the whole chunk of kernel() in main.c line 394 will need to be moved to a p_0 procedure in task.c * that chunk needs to be replaced by a init_call_p_0() * init_call_p_0() will need to (in a .asm file): set SS and DS to the DOS data segment (DGROUP, cs:[_DGROUP_]) set SP to the top of a special p_0 stack (how many bytes for that stack?) * and jump to reloc_call_p_0(), where reloc_call_p_0 is a special entry in kernel.asm (like the other reloc_call's). Not sure when I get to this though. Of course Lucho, feel free to try and you'll learn a bit too so you can be an expert :) Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Borland C 386 bug
On Wed, 11 Feb 2004, Luchezar Georgiev wrote: INIT_FMEMCPY: |INIT_FMEMCPY: enter 8,0|pushBP mov DX,4[BP] |mov BP,SP mov EAX,0Ah[BP]|mov DX,4[BP] mov -4[BP],EAX |jmp short L76 mov EAX,6[BP] |L64:les BX,6[BP] mov -8[BP],EAX |mov AL,ES:[BX] jmp short L92|les BX,0Ah[BP] L80:les BX,-8[BP] |mov ES:[BX],AL mov AL,ES:[BX] |inc word ptr 6[BP] les BX,-4[BP] |inc word ptr 0Ah[BP] mov ES:[BX],AL |L76:mov AX,DX inc word ptr -8[BP]|dec DX inc word ptr -4[BP]|or AX,AX L92:mov AX,DX |jne L64 dec DX |pop BP or AX,AX |ret 0Ah jne L80| leave | ret 0Ah| Well I see no bug in this fmemcpy. One other thing I can imagine being a problem is that some device drivers or programs you use rely on the high word of eax being zero. since you said: after the install commands are processed (if any). This means that if no install was present no problems occurred? so what you could try is to add a xor eax, eax at a strategic place, ie. _exec_user: xor eax, eax in procsupt.asm. Also execrh.asm for device drivers. Hmm, reminds of some bug in bugzilla ... Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
