[Freedos-kernel] devicehigh semi-patch
each DEVICEHIGH in config.c causes a warning
[ http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1759 ]
is the document for getting Openwatcom packages (in order to compile the kernel) still correct
(except OpenWatcom 1.0 - 1.2 then)?
http://www.freedos.org/freedos/news/newsitem/137.txt
idea (excuse my lack of C knowledge):
static bool umbwarn=true; // somewhere in the start of config.c
and then check at DEVICEHIGH (line 1311):
STATIC VOID DeviceHigh(BYTE * pLine)
{
if(umbwarn) // true unless warning already given.
{
if (UmbState == 1)
{
if (LoadDevice(pLine, MK_FP(umb_start + UMB_top, 0), TRUE) == DE_NOMEM)
{
printf(Not enough free memory in UMB's: loading low\n);
}
}
else
{
printf(UMB's unavailable!\n);
}
umbwarn=false; // only warn user once about lack of UMBs, not for each DEVICEHIGH
}
LoadDevice(pLine, lpTop, FALSE);
}
Bernd
---
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] 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 :-/ Erwin --- 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] new conv mem highs.
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 ok that's good. It means that that panic was justified to implement for me as a failsafe. Remember CVS is for (public) development, released kernels should never have this behaviour so I'll have to fix something... Sure, not meant for end-users. I just figured it would be good to raise an alert about the current kernel to back up Lucho's remark. Bart Erwin --- 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] new conv mem highs.
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 if files=10 would work for you, then there are 10 of those f-nodes. maybe that's the minimum that should be kept in conventional memory? move all i-nodes except (the first?/lowest?) 10 into HMA don't know if this is possible. Bart is the expert here. Bernd --- 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
[Freedos-kernel] BUGS
Hi! __O\_/_\_/O__ inthndlr.c/int2F_12_handler: - bug: INT2F/4A01: instead available size in BX always returned 0. - bug: INT2F/1213 should return AL, not AX. - bug: blockio.c/AllocateHMASpace(): wrongly freed extra buffer because FP_OFF(bp+1) = lowbuffer expression (should be ). config.c: - NBUFF (default and min allowed value for buffers=) is set to 20 (too high); code to allocate min 6 buffers already present in config_init_buffers(). config.c/config_init_buffers(): - bug: with argument=-1, firstAvailableBuf points to first buffer, not to next following buffer. - value of buffers= (say 80) ignored, if it positive and HMA present. - if HMA present, but buffers in low memory (buffers=-80), then memory after kernel in HMA not available for INT2F/4A0x (firstAvailableBuf not points to HMA); support for this requires also modification in blockio.c/AllocateHMASpace(): if (FP_SEG (firstbuf) != /*HMASEG*/0x) return; _ O/~\ /~\O In next letter I present patches, which will fix all of these bugs and inconsistencies, also as reduce kernel size after BC: in memory by 176 bytes, unpacked executable by 182 bytes. And YES, all of this tested - both in original (2033) kernel and in kernel with my updates. PS: In inthndlr.asm present string FreeDOS kernel version 1.1.33 ... (total 67 characters), because os_release variable in globals.h; this variable used by INT 21/33FF, which is FreeDOS extension (see int21_syscall()). --- 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
[Freedos-kernel] patch: config.c
config.pat Description: Binary data
