Re: [Freedos-kernel] Re: Optimization idea: DIV/MODULO never full 32=32/32bit
Hi! 21-Июл-2004 02:07 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: >> + jcxz%%div3216 ; cx=0 -> divisor < 2^16 EA> [ALL this code is NEVER reached in KERNEL now] EA> [So you can add some "panic" here, e.g. deliberately divide by zero...] EA> [...and then you have only he following left:] Try this yourself and wonder, why (current) kernel size will not be reduced (even for Watcom, for which this code is developed). Or, later, when fill division appear somewhere in kernel, spend _your_ time to find bug in your kernel edition with reduced division. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Optimization idea: DIV/MODULO never full 32=32/32bit
Hi! I mean: > + jcxz%%div3216 ; cx=0 -> divisor < 2^16 [ALL this code is NEVER reached in KERNEL now] [So you can add some "panic" here, e.g. deliberately divide by zero...] [...and then you have only he following left:] > +%%div3216: > + cmp dx,bx ; xh < y ? > + jb %%one_div ; yes, one division sufficient > + > + xchgcx,ax ; ax=0, cx=xl > + xchgax,dx ; dx:ax=0:xh, cx=xl > + div bx ; ax=xh/y, dx=xh%y, cx=xl > + xchgax,cx ; dx:ax=xh%y*w+xl=xt, cx=xh/y > + > +%%one_div: > + div bx ; ax=xt/y, dx=xt%d=x%d, cx=xh/y > + mov bx,dx ; bx=x%d > + mov dx,cx ; dx:ax=xh/y*w+xt/y=x/y > + xor cx,cx ; cx:bx=x%d > ret Pretty short, huh? This only affects the 8086 version of the code, the 386 division/modulo code already trivially handles 32=64/32bit with a single "div" command anyway (as visible in the patch by Arkady). which is more than the 8086 16=32/16 bit can do. But TWO steps with 16=32/16 bit each are enough to get 32=32/16 bit results! This means that we can remove the complicated 8086 32=32/32 bit code. The code for 386 is not changed. http://www.coli.uni-sb.de/~eric/kernelmodulo.txt Eric --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Optimization idea: DIV/MODULO never full 32=32/32bit
Hi! 21-Июл-2004 00:07 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> Hi, I took the effort to grep through the whole 2035 kernel sources, EA> to find divisions and modulo calculations. Some results: For which reasons? What is your purpose? EA> * for "c = a/b, d = a%b" I found NO places where b can be above 64k, EA> but SOME places where c can be above 64k. This means: The big bit-by-bit- EA> division loop can be removed (let "division overflow" handle the rest). How you plan to "remove bit-by-bit division loop"? First, under Watcom in kernel is no such loop. Second, you can't affect which code (and calls) compiler generates (unless you rework source code to something other). --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Optimization idea: DIV/MODULO never full 32=32/32bit
Hi, I took the effort to grep through the whole 2035 kernel sources, to find divisions and modulo calculations. Some results: * division/modulo macro should have an "if x/512 then ..." shortcut, especially for older CPUs where division is slow. We often divide by sector size, but without KNOWING in advance that this will be 512 (because we still have the hope that all SEC_SIZE - defined as 512 - will eventually be replaced by "real sector size for this drive", to allow the kernel to handle other sector sizes). * for "c = a/b, d = a%b" I found NO places where b can be above 64k, but SOME places where c can be above 64k. This means: The big bit-by-bit- division loop can be removed (let "division overflow" handle the rest). The places where c is above 64k are already special-cased: Two single 32:16=16bit divisions implement that (because d is always 16 bit only, two 32:16=16bit divisions are actually enough for that case!) Arkady already tuned the two LBA_to_CHS variants... Somebody else already tuned the clock driver: ticks = ((ticks / 59659u) << 16) + ((ticks % 59659u) << 16) / 59659u; ... scaling factor 1193180/6553600 = 59659/327680 = 59659/65536/5 ... Ticks = ((hs >> 16) * 59659u + (((hs & 0x) * 59659u) >> 16)) / 5; ... which also uses a simplified (works 1901 to 2199) leap year detection, too. The link_fat thing might look tricky, but it divides by 2*, 0.5* or 0.25* sector size only. It might be interesting to use a shift for that (sector sizes are always powers of 2) if there is a nice way to quickly get the right shift count. The prf.c and put_unsigned base conversion things are two of VERY few places where the result of a division can be > 64k, but again, such divisions still do not need the full bit by bit processing loop ;-). FCB stuff sometimes divides by record size, but values are clipped to 64k in some aspects here. FAT calculations for bpb processing (cluster count, fat size in bytes), using cdiv(a, b) (((a) + (b) - 1) / (b)), usually divide by sector size based values: FAT size * 0.25, * 0.5, * 2/3 ... (Is defbpb->bpb_nsector right Argh, I meant CLUSTER size of course. So still everything with (b) < "32.1k" in the cdiv division. Right after that, you have a division by things like 4 or the sector size... there you can get RESULTS above 64k, but still the "two step division" is enough, no loop needed. (and results above 64k only happen for FATs > 32 MB, which is only needed for drives > 512 GB but which can happen for drive > 4 GB for tiny clusters). Another thing which I noted: getbpb() has no clipping of ddt_ncyl value, I assume it intentionally returns the result modulo 64k? No real problem because using > 64k disk cylinders is impossible anyway. FreeDOS will even refuse to use > 1k disk cylinders, and will use LBA instead. The ddt_ncyl field is not READ for anything by FreeDOS itself. Only in the standalone programs (exeflat, sys), I found one single really huge division: return x.xfs_freeclusters > (bytes / (x.xfs_clussize * x.xfs_secsize)); This can be a division by 64k if cluster size is 64k. Could be easily special-cased, but having an inefficient "huge div loop" in SYS doesn't hurt. As long as we now know that the WORST case in the entire KERNEL is already the one which is handled by simple "two step div". Please correct me if I missed any place where a real "huge div loop" would be needed. See also my notes (only temporarily online) at: http://www.coli.uni-sb.de/~eric/kernelmodulo.txt (88 lines, as I removed all "boring" cases like "... = .../constant" already) Eric --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: dsk.c
Hi! 20-Июл-2004 22:04 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> So "small bugfix" must be clarified as "if you use ONE (not sure which) EA> dsk.c patch from Arkady, "If you use 2035a... EA> you *must* also use this 'small bugfix' patch, ...you must apply this patch". EA> Arkady, if you do not start explaining in more detail WHY you patch EA> WHAT and HOW, WHY: bug; my fault. WHAT: dsk.c. HOW: changing source. _Here_ all clear and fix here is a fix, not change, thus here not need more explanations. EA> The whole optimization of this code seems to have started because some EA> compiler created "big" code "if ... then AL=0 else AL=1", with some EA> jumps... And because BC doesn't optimizes far pointers and long values. EA> Or try: rp->>r_ai->AI_Flag = 0; EA> if (!(descflags & DF_NOACCESS)) rp->r_ai->AI_Flag++; Eric, I already say you, that you have not enough experience in studying listings. Original listing for access AI_Flag includes: mov es,word ptr [bp-10H] mov bx,word ptr es:[bx+13H] mov si,word ptr [bp-0eH] mov es,word ptr es:[si+15H] Now double this code, and you get your "optimization". In theory, for some compilers this may be solved with help of another temporary vatiable: UBYTE flag = 0; if (...) flag++; rp->r_ai->AI_Flag = flag; But, at least for TC/BC, such code (eve with "register" word) usually generates stack variable. Thus: least possible 16-bit assembler code is 7-8 bytes. Currently, for my C code generated 10 bytes. _If_ you wish to optimize it more, try this. If you find (not suggest!) way to get shorter code (without hardly disturbing source) - fine. I already do what I may. EA> Whatever, this discussion has been going on off-list for 10 mails or EA> so, while we are actually only talking about at most +/- 6 byte EA> optimization. So why you continue this thread? EA> And no, if it is 7 byte, you do not have to write a clarifying answer on EA> list. ? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: patch: dsk.c
> - small bugfix. Which is, for function 0x67: rp->r_ai->AI_Flag = (UBYTE)~(descflags / DF_NOACCESS) & 1; Basically it makes the function work as before, or as, for example: rp->r_ai->Al_Flag = !(descflags & DF_NOACCESS); Original code was: > case 0x47: /* set access flag */ > pddt->ddt_descflags |= DF_NOACCESS; > if (rp->r_ai->AI_Flag) > pddt->ddt_descflags &= ~DF_NOACCESS; So "small bugfix" must be clarified as "if you use ONE (not sure which) dsk.c patch from Arkady, you *must* also use this 'small bugfix' patch, because the first patch accidentally inverted the result..." The broken disk access flag was the reason for "kernel 2035a does not allow FORMAT to access harddisk partitions unless they already have a valid FAT filesystem". Arkady, if you do not start explaining in more detail WHY you patch WHAT and HOW, then those people who cannot read all your patches (because they are less fluent in C than in English) will miss the really useful patches which are hidden behind optimizations. By the way, any compiler which would be smart enough to translate the code to "test dh,2 setz al" for 386+, assuming that AL will be written to Al_Flag and DX contains descflags? The whole optimization of this code seems to have started because some compiler created "big" code "if ... then AL=0 else AL=1", with some jumps... Arkady then used the division method, which is supposed to be optimized to a shift (works on "all" compilers, but for 8086 code this means that you need "mov cl,9 shr dx,cl ...". Still, the shift avoids ONE compiler stupidity (several jumps) at the cost of risking ANOTHER compiler stupidity (actual use of division). Plus I think NO compiler will be clever enough to see that the "division" can not only be implemented as "shift" but actually only is a "test/setz". Chances for the latter should be much better with the ORIGINAL 2035a code. Or try: rp->r_ai->AI_Flag = 0; if (!(descflags & DF_NOACCESS)) rp->r_ai->AI_Flag++; Whatever, this discussion has been going on off-list for 10 mails or so, while we are actually only talking about at most +/- 6 byte optimization. And no, if it is 7 byte, you do not have to write a clarifying answer on list. Eric --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: FreeCOM
Hi! 20-Июл-2004 18:52 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> By the way, FDAPM is looking for COMSPEC to know if it is run from EA> INSTALL. Not 100% bulletproof, but, probably, best available solution. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch: main.c
Hi!
Under the hard pressure of tom, Steffen and Eric, I prepare patch for
main.c. Now, into empty environment before calling SHELL added "PATH=.".
Also, there small optimization.
--- Begin Message ---
diff -ruNp old/kernel/main.c new/kernel/main.c
--- old/kernel/main.c 2004-07-18 07:52:18.0 +
+++ new/kernel/main.c 2004-07-20 20:12:36.0 +
@@ -195,6 +195,12 @@ STATIC void PSPInit(void)
/* this area reused for master environment */
/*p->ps_cmd.ctCount = 0;*/ /* local command line */
/*p->ps_cmd.ctBuffer[0] = '\r';*/ /* command tail*/
+
+ /* !!! dirty hack: because bug in old FreeCOM, which wrongly
+ process empty environment in MS-DOS style, garbage empty
+ environment by dummy variable: --avb
+ */
+ fmemcpy(&p->ps_cmd, "PATH=.", 6/*strlen("PATH=.")*/);
}
#ifndef __WATCOMC__
@@ -328,8 +334,10 @@ STATIC VOID FsConfig(VOID)
for (i = 0; i < LoL->lastdrive; i++)
{
struct cds FAR *pcds_table = &LoL->CDSp[i];
-fmemcpy(pcds_table->cdsCurrentPath, "A:\\", 4);
-pcds_table->cdsCurrentPath[0] += i;
+pcds_table->cdsCurrentPath[0] = 'A' + i;
+pcds_table->cdsCurrentPath[1] = ':';
+pcds_table->cdsCurrentPath[2] = '\\';
+pcds_table->cdsCurrentPath[3] = '\0';
pcds_table->cdsFlags = 0;
if (i < LoL->nblkdev && (LONG) dpb != -1l)
{
--- End Message ---
[Freedos-kernel] patch: dsk.c
Hi!
- small optimization (induced by Eric).
--- Begin Message ---
diff -ruNp old/kernel/dsk.c new/kernel/dsk.c
--- old/kernel/dsk.c2004-07-20 22:27:16.0 +
+++ new/kernel/dsk.c2004-07-20 22:16:48.0 +
@@ -804,32 +804,22 @@ STATIC WORD dskerr(COUNT code)
translate LBA sectors into CHS addressing
*/
-STATIC int LBA_to_CHS(ULONG LBA_address, struct CHS *chs, const ddt * pddt)
+STATIC void LBA_to_CHS(ULONG LBA_address, struct CHS *chs, const ddt * pddt)
{
/* we need the defbpb values since those are taken from the
BIOS, not from some random boot sector, except when
we're dealing with a floppy */
- const bpb *pbpb = hd(pddt->ddt_descflags) ? &pddt->ddt_defbpb : &pddt->ddt_bpb;
- unsigned hs = pbpb->bpb_nsecs * pbpb->bpb_nheads;
- unsigned hsrem = (unsigned)(LBA_address % hs);
-
- LBA_address /= hs;
-
- if (LBA_address > 1023ul)
+ const bpb *p = hd(pddt->ddt_descflags) ? &pddt->ddt_defbpb : &pddt->ddt_bpb;
+ unsigned hs = p->bpb_nsecs * p->bpb_nheads;
+ chs->Cylinder = 0xu;
+ if (hs > hiword(LBA_address))/* LBA_address < hs * 0x1ul */
{
-#ifdef DEBUG
-printf("LBA-Transfer error : cylinder %lu > 1023\n", LBA_address);
-#else
-put_string("LBA-Transfer error : cylinder > 1023\n");
-#endif
-return 1;
+chs->Cylinder = (unsigned)(LBA_address / hs);
+ hs = (unsigned)(LBA_address % hs);
+chs->Head = hs / p->bpb_nsecs;
+chs->Sector = hs % p->bpb_nsecs + 1;
}
-
- chs->Cylinder = (UWORD)LBA_address;
- chs->Head = hsrem / pbpb->bpb_nsecs;
- chs->Sector = hsrem % pbpb->bpb_nsecs + 1;
- return 0;
}
/* Test for 64K boundary crossing and return count small*/
@@ -945,8 +935,16 @@ STATIC int LBA_Transfer(ddt * pddt, UWOR
else
{ /* transfer data, using old bios functions */
struct CHS chs;
-if (LBA_to_CHS(LBA_address, &chs, pddt))
+LBA_to_CHS(LBA_address, &chs, pddt);
+if (chs.Cylinder > 1023u)
+{
+#ifdef DEBUG
+ printf("IO error: cylinder (%u) > 1023\n", chs.Cylinder);
+#else
+ put_string("IO error: cylinder > 1023\n");
+#endif
return failure(E_CMD); /*dskerr(1)*/
+}
/* avoid overflow at end of track */
if (count > pddt->ddt_bpb.bpb_nsecs + 1 - chs.Sector)
--- End Message ---
[Freedos-kernel] patch: dsk.c
Hi! - small bugfix. --- Begin Message --- diff -ruNp old/kernel/dsk.c new/kernel/dsk.c --- old/kernel/dsk.c2004-06-11 04:47:48.0 + +++ new/kernel/dsk.c2004-07-20 22:27:16.0 + @@ -711,7 +711,7 @@ STATIC WORD Genblkdev(rqptr rp, ddt * pd break; } case 0x67: /* get access flag */ - rp->r_ai->AI_Flag = (descflags / DF_NOACCESS) & 1; /* bit 9 */ + rp->r_ai->AI_Flag = (UBYTE)~(descflags / DF_NOACCESS) & 1; /* bit 9 */ break; default: return failure(E_CMD); --- End Message ---
Re: [Freedos-kernel] Re: FreeCOM
->>> BREAKS FreeCOM and possibly also FDAPMs "Am I run from INSTALL=?" > 1. MS-DOS-style mean two \0 and 2035a produces two \0. EA>> So Arkady has optimized away 4 "wasted" bytes in environment, > 6. PLONK. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Re: FreeCOM
Hi, sorry, I swapped \0\0c:\\freecom.com with \0c:\\freecom.com then... Anyway, if you "waste" 3 bytes to do: A=B\0\0c:\\freecom.com\0 instead of \0\0c:\\freecom.com\0 ... then everybody will be happy! By the way, FDAPM is looking for COMSPEC to know if it is run from INSTALL. This should be working well enough with both 2035 and 2035a. The reason is the wish that FDAPM without command line arguments should show DIFFERENT behaviour when started from INSTALL than when started from shell / prompt / batch file. If you are evil, you can add a SET COMSPEC... to your config,sys, but nothing really important will break anyway. Eric --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeCOM
Hi! 20-Июл-2004 17:09 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> Hi, even though you now have an (0.82pl3w? 0.82pl3v EA> Testing, unstable!) FreeCOM, Same for 2035a - it _called_ unstable (bad name, BTW), but it includes optimizations, fixes and features. Thus, fixed kernel plus fixed FreeCOM - very good. EA> \0c:\freecom.com ->> BREAKS FreeCOM and possibly also FDAPMs "Am I run from INSTALL=?" 1. MS-DOS-style mean two \0 and 2035a produces two \0. 2. There are no reliable/portable way how to detect if you run from config.sys. Suggesting empty environment as indicator of INSTALL= is wrong: you may be called with empty environment at any time. And vice versa: INSTALL= (now!) may be called with non-empty environment, if there is menu or SETs in config.sys. BTW, why FDAPM should suggest INSTALL=? EA> Correct behaviour: EA> pointer = start of environment I already explain all of this for Steffen, but patch from tom was prepared much earlier. EA> \0c:\freecom.com\0 is only understood by CORRECT programs like SMARTDRV Wrong. Smartdrv expects \0\0. EA> \0\0c:\freecom.com\0 is only understood by BUGGY but COMMON programs like EA> FreeCOM Wrong. FreeCOM (was) expects one \0, smartdrv - two \0\0. EA> So Arkady has optimized away 4 "wasted" bytes in environment, 6. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: FreeCOM
Hi, even though you now have an (0.82pl3w? Testing, unstable!)
FreeCOM, you STILL should "waste" those FEW BYTES in the environment
to maintain FreeCOM compatibility!
There is TRANSLATED FreeCOM, STABLE FreeCOM, DEBUGGING FreeCOM,
NON XMS SWAP FreeCOM, and possibly many other reasons why people
cannot upgrade to the FIXED FreeCOM. Still they want to be able
to test your kernel, even with F5 mode!!!
Problem:
some=var\0other=var\0\0c:\freecom.com
-> works with BOTH smartdrv and all FreeCOM versions
\0c:\freecom.com
-> BREAKS FreeCOM and possibly also FDAPMs "Am I run from INSTALL=?"
detection: FreeCOM erroneously searches for "\0\0" as marker to
find "c:\freecom.com" string, and FDAPM (and possibly several
other programs!) searches for "\0\0" as marker to where it can
stop looking for COMSPEC (if no COMSPEC found, FDAPM assumes
that it is being run from INSTALL). In FreeCOM this means CRASH
but in FDAPM this only crashes if there is no "\0\0" before the
scan reaches environment:0x offset.
Correct behaviour:
pointer = start of environment
while (*pointer) {
copy string at pointer, including the trailing \0, and
update pointer to point after that trailing \0
}
pointer++; /* skip over the "end of variables" \0 which we found */
string at pointer (possibly empty) up to and including the trailing \0,
is the name of the program
However, COMMON behaviour is:
do {
copy string at pointer, including the trailing \0 ...
(or skip over it)
} until (!*pointer);
pointer++;
string at pointer is ...
Or in other programs, which are not interested in environment variables:
while (pointer[0] || pointer[1]) pointer++;
The BUG in this common behaviour: The two consecutive \0 are only an
artifact of "end of an environment variable string" being right before
"\0 which marks upcoming name-of-program string". Result:
\0c:\freecom.com\0 is only understood by CORRECT programs like SMARTDRV
\0\0c:\freecom.com\0 is only understood by BUGGY but COMMON programs like FreeCOM
*but*
A=B\0\0c:\freecom.com\0 is understood by ALL programs, I dare to say.
So Arkady has optimized away 4 "wasted" bytes in environment, but we *need*
them to make ALL programs work! The "A=B\0" is, however, ONLY needed for
SHELL/INSTALL lines and ONLY if there are no SET events before and if there
is no CONFIG=7 or anything in the environment anyway.
In other words: Only for non-multiconfig we would waste 4 bytes per environment
for the sake of being compatible to all programs! I think we *must* pay this
price, even though mathematical logics tell use the programs *should* accept
\0c:\freecom.com\0 after all.
Please re-add such a workaround (old string was "PATH=.\0" I think)
instead of forcing us to upgrade all versions of FreeCOM and possibly also
other programs. I think saving four bytes of kludge RAM are not worth
forcing us all to upgrade FreeCOM.
Eric
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeCOM
Arkady V.Belousov schreef: At last, Lucho prepares for me executable of FreeCOM from CVS (version 0.82pl3v). Now this edition is shorter (67k instead 95k) and it works with empty environment. Lucho places it on his site, I also may resend this executable for those, who need. Phew. PS: Kenneth, (if and) when you place executable of 2035a (somewhere), don't forget to include into archive fixed FreeCOM. hm..I'll take a look at this FreeCOM as soon as possible. For me, FreeCOM bugs are a bit troublesome as they tend to show up in my batchfiles that I use for the FreeDOS cdrom. Somewhere this week..as a student I have to work during the summer to pay for my living during the rest of the year. which ofcourse means not that much time and not always willing to dedicate time to FreeDOS - first work, then relax (games, tv, etc), then FreeDOS. Sorry if this is causing any delays (and for me a huge mail archive to look at for finding patches and other improvements made during the last few months). Bernd --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch: dosfns.c
Hi!
- slightly more comments.
--- Begin Message ---
diff -ruNp old/kernel/dosfns.c new/kernel/dosfns.c
--- old/kernel/dosfns.c 2004-07-20 16:59:04.0 +
+++ new/kernel/dosfns.c 2004-07-20 17:57:38.0 +
@@ -1015,7 +1015,7 @@ STATIC int pop_dmp(int rc, dmatch FAR *
dta = save_dta;
if (rc == SUCCESS)
{
-fmemcpy(save_dta, &sda_tmp_dm, 21);
+fmemcpy(save_dta, &sda_tmp_dm, 21/*offsetof(save_dta->dm_attr_fnd)*/);
save_dta->dm_attr_fnd = SearchDir.dir_attrib;
save_dta->dm_time = SearchDir.dir_time;
save_dta->dm_date = SearchDir.dir_date;
@@ -1080,7 +1080,7 @@ COUNT DosFindNext(void)
{
dmatch FAR *save_dta = dta;
- /* findnext will always fail on a device name device name or volume id */
+ /* findnext fail on a device name and volume id */
if (save_dta->dm_attr_fnd & (D_DEVICE | D_VOLID))
return DE_NFILES;
@@ -1101,10 +1101,7 @@ COUNT DosFindNext(void)
* RBIL says that findnext can only return one error type anyway
* (12h, DE_NFILES)
*/
-#if 0
- printf("findnext: %d\n", save_dta->dm_drive);
-#endif
- fmemcpy(dta = &sda_tmp_dm, save_dta, 21);
+ fmemcpy(dta = &sda_tmp_dm, save_dta, 21/*offsetof(save_dta->dm_attr_fnd)*/);
memset(&SearchDir, 0, sizeof(struct dirent));
return pop_dmp(sda_tmp_dm.dm_drive & 0x80
? network_redirector_fp(REM_FINDNEXT, &sda_tmp_dm)
--- End Message ---
[Freedos-kernel] OW and RTL relocation
Hi! Bart, what happen when OW will be fixed and from segments with non-standard names will be generated FAR calls to RTL? In this case current kernel implementation will be broken (because currently __U4M and __U4D placed into relocatable HMA_TEXT, not into fixed _TEXT)? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch: dosfns.c
Hi!
- optimization for SftSeek(); later it will be optimized together with
DosSeek() to make better calling from inthndlr.c.
- common code from DosFindFirst() and DosFindNext() moved to pop_dmp().
--- Begin Message ---
diff -ruNp old/kernel/dosfns.c new/kernel/dosfns.c
--- old/kernel/dosfns.c 2004-05-23 14:18:10.0 +
+++ new/kernel/dosfns.c 2004-07-20 16:59:04.0 +
@@ -308,22 +308,31 @@ long DosRWSft(int sft_idx, size_t n, voi
}
}
-COUNT SftSeek(int sft_idx, LONG new_pos, COUNT mode)
+#define SEEK_SET 0
+#define SEEK_CUR 1
+#define SEEK_END 2
+
+/* !!! `mode' should be `unsigned' --avb */
+int SftSeek(int sft_idx, LONG new_pos, int mode)
{
sft FAR *s = idx_to_sft(sft_idx);
if (FP_OFF(s) == (size_t) -1)
return DE_INVLDHNDL;
/* Test for invalid mode*/
- if (mode < 0 || mode > 2)
+ if ((unsigned)mode > SEEK_END) /* 2 */
return DE_INVLDFUNC;
lpCurSft = s;
if (s->sft_flags & SFT_FSHARED)
{
+if (mode == SEEK_CUR)
+{
+ new_pos += s->sft_posit;
+}
/* seek from end of file */
-if (mode == 2)
+else if (mode == SEEK_END)
{
/*
* RB list has it as Note:
@@ -336,41 +345,24 @@ COUNT SftSeek(int sft_idx, LONG new_pos,
* Mfs.c looks for these mode bits set, so here is my best guess.;^)
*/
if (s->sft_mode & (O_DENYREAD | O_DENYNONE))
-s->sft_posit = remote_lseek(s, new_pos);
+new_pos = remote_lseek(s, new_pos);
else
-s->sft_posit = s->sft_size + new_pos;
- return SUCCESS;
-}
-if (mode == 0)
-{
- s->sft_posit = new_pos;
- return SUCCESS;
-}
-if (mode == 1)
-{
- s->sft_posit += new_pos;
- return SUCCESS;
+new_pos += s->sft_size;
}
-return DE_INVLDFUNC;
}
-
/* Do special return for character devices */
- if (s->sft_flags & SFT_FDEVICE)
+ else if (s->sft_flags & SFT_FDEVICE)
{
-s->sft_posit = 0l;
-return SUCCESS;
+new_pos = 0;
}
else
{
-LONG result = dos_lseek(s->sft_status, new_pos, mode);
-if (result < 0l)
- return (int)result;
-else
-{
- s->sft_posit = result;
- return SUCCESS;
-}
+if ((new_pos = dos_lseek(s->sft_status, new_pos, mode)) < 0)
+ return (int)new_pos;
}
+
+ s->sft_posit = new_pos;
+ return SUCCESS;
}
ULONG DosSeek(unsigned hndl, LONG new_pos, COUNT mode)
@@ -1018,22 +1010,27 @@ COUNT DosChangeDir(BYTE FAR * s)
return SUCCESS;
}
-STATIC VOID pop_dmp(dmatch FAR * dmp)
+STATIC int pop_dmp(int rc, dmatch FAR * save_dta)
{
- dmp->dm_attr_fnd = (BYTE) SearchDir.dir_attrib;
- dmp->dm_time = SearchDir.dir_time;
- dmp->dm_date = SearchDir.dir_date;
- dmp->dm_size = (LONG) SearchDir.dir_size;
- ConvertName83ToNameSZ(dmp->dm_name, (BYTE FAR *) SearchDir.dir_name);
+ dta = save_dta;
+ if (rc == SUCCESS)
+ {
+fmemcpy(save_dta, &sda_tmp_dm, 21);
+save_dta->dm_attr_fnd = SearchDir.dir_attrib;
+save_dta->dm_time = SearchDir.dir_time;
+save_dta->dm_date = SearchDir.dir_date;
+save_dta->dm_size = SearchDir.dir_size;
+ConvertName83ToNameSZ(save_dta->dm_name, SearchDir.dir_name);
+ }
+ return rc;
}
+/* !!! `name' should be `const char FAR*' --avb */
COUNT DosFindFirst(UCOUNT attr, BYTE FAR * name)
{
- int rc;
- register dmatch FAR *dmp = dta;
-
- rc = truename(name, PriPathName,
-CDS_MODE_CHECK_DEV_PATH | CDS_MODE_ALLOW_WILDCARDS);
+ dmatch FAR *save_dta = dta;
+ int rc = truename(name, PriPathName,
+CDS_MODE_CHECK_DEV_PATH | CDS_MODE_ALLOW_WILDCARDS);
if (rc < SUCCESS)
return rc;
@@ -1065,32 +1062,26 @@ COUNT DosFindFirst(UCOUNT attr, BYTE FAR
SearchDir.dir_attrib = D_DEVICE;
SearchDir.dir_time = dos_gettime();
SearchDir.dir_date = dos_getdate();
-p = (char *)FP_OFF(get_root(PriPathName));
-memset(SearchDir.dir_name, ' ', FNAME_SIZE + FEXT_SIZE);
+p = (const char *)get_root(PriPathName);
for (i = 0; i < FNAME_SIZE && *p && *p != '.'; i++)
SearchDir.dir_name[i] = *p++;
+for (; i < FNAME_SIZE + FEXT_SIZE; i++)
+ SearchDir.dir_name[i] = ' ';
rc = SUCCESS;
/* /// End of additions. - Ron Cemer ; heavily edited - Bart Oldeman */
}
else
rc = dos_findfirst(attr, PriPathName);
- dta = dmp;
- if (rc == SUCCESS)
- {
-fmemcpy(dta, &sda_tmp_dm, 21);
-pop_dmp(dmp);
- }
- return rc;
+ return pop_dmp(rc, save_dta);
}
COUNT DosFindNext(void)
{
- COUNT rc;
- register dmatch FAR *dmp = dta;
+ dmatch FAR *save_dta = dta;
/* findnext will always fail on a device name device name or volume id */
- if (dmp->dm_attr_fnd & (D_DEVICE | D_VOLID))
+ if (save_dta->dm_attr_fnd & (D_DEVICE | D_VOLID))
return DE_NFILES;
/*
@@ -,21 +1102,13 @@ COUNT DosFindNext(void)
* (12h, DE_NFILES)
*/
#if 0
- printf("findnext: %d\n", dmp->dm_drive);
+ printf("findnext: %d\n", save_dta->dm_drive);
#endif
- fmemcpy(&sda_tmp_dm, d
Re: [Freedos-kernel] Re: [Freedos-cvs] mem/source/mem mem.c,1.7,1.8
Hi!
20-Июл-2004 22:26 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> BO> +while (mlist!=NULL && mlist->seg != lastconseg) {
>> ^^^
>> BO> +/* should not be reached anymore: */
>> BO> +if (mlist->next==NULL)
>> -^
>> BO> mlist=mlist->next;
>> As I already report, "mlist->next==NULL" will never happen, but
>> "mlist==NULL" is possible, thus bug with dereferencing NULL is remained.
BO> Did Eric agree with you? He didn't send me an update.
"Agreed" about what? Notwithstanding if Eric agreed or not (though, I
notify he when look at his patch), but after above mentioned loop `mlist'
may be NULL, and current code not prevents to dereference NULL pointer.
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] dosfns.c: bug?
Hi! __O\_/_\_/O__ COUNT DosFindFirst(UCOUNT attr, BYTE FAR * name) if (rc & IS_NETWORK) rc = network_redirector_fp(REM_FINDFIRST, current_ldt); >-^^^ COUNT DosFindNext(void) rc = (sda_tmp_dm.dm_drive & 0x80) ? network_redirector_fp(REM_FINDNEXT, &sda_tmp_dm) : dos_findnext(); >---^^^ _ O/~\ /~\O Isn't this bug when used pointer to CDS instead pointer to sda_tmp_dm? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Q: changing DTA
Hi! Why dosfns.c:DosFindFirst() and DosFindNext() changes `dta' pointer while processing search (dos_findfirst()/dos_findnext() and network_redirector_fp())? Isn't this is wrong? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch: *.h
Hi!
- (Eric) cleanup for types. This _not_ changes generated code.
--- Begin Message ---
diff -ruNp old/hdr/dcb.h new/hdr/dcb.h
--- old/hdr/dcb.h 2002-12-08 16:17:16.0 +
+++ new/hdr/dcb.h 2004-07-20 15:08:40.0 +
@@ -80,8 +80,8 @@ struct dpb {
ULONG dpb_xdata;
ULONG dpb_xsize; /* # of clusters+1 on media */
ULONG dpb_xfatsize; /* # of sectors / FAT */
- ULONG dpb_xrootclst; /* starting cluster of root dir */
- ULONG dpb_xcluster; /* cluster # of first free */
+ CLUSTER dpb_xrootclst;/* starting cluster of root dir */
+ CLUSTER dpb_xcluster; /* cluster # of first free */
/* -1 if not known */
#endif
};
@@ -89,4 +89,3 @@ struct dpb {
#define UNKNCLUSTER 0x /* see RBIL INT 21/AH=52 entry */
#define XUNKNCLSTFREE0xl/* unknown for DOS */
#define UNKNCLSTFREE 0x /* unknown for DOS */
-
diff -ruNp old/hdr/device.h new/hdr/device.h
--- old/hdr/device.h2004-05-29 02:51:28.0 +
+++ new/hdr/device.h2004-07-20 15:09:46.0 +
@@ -174,7 +174,7 @@ typedef struct {
/* bits 6-4: reserved (0) */
/* bits 3-0: active FAT number */
UWORD bpb_xfsversion; /* filesystem version */
- ULONG bpb_xrootclst; /* starting cluster of root dir */
+ CLUSTER bpb_xrootclst;/* starting cluster of root dir */
UWORD bpb_xfsinfosec; /* FS info sector number, */
/* 0x if unknown*/
UWORD bpb_xbackupsec; /* backup boot sector number*/
diff -ruNp old/hdr/dirmatch.h new/hdr/dirmatch.h
--- old/hdr/dirmatch.h 2002-12-08 16:17:16.0 +
+++ new/hdr/dirmatch.h 2004-07-20 15:06:50.0 +
@@ -37,33 +37,26 @@ static BYTE *dirmatch_hRcsId =
typedef struct {
UBYTE dm_drive;
- BYTE dm_name_pat[FNAME_SIZE + FEXT_SIZE];
- BYTE dm_attr_srch;
+ char dm_name_pat[FNAME_SIZE + FEXT_SIZE];
+ BYTE dm_attr_srch; /* should be UBYTE --avb*/
UWORD dm_entry;
-#ifdef WITHFAT32
- ULONG dm_dircluster;
-#else
- UWORD dm_dircluster;
+ CLUSTER dm_dircluster;
+#ifndef WITHFAT32
UWORD reserved;
#endif
struct {
-BITS/* directory has been modified */
-f_dmod:1;
-BITS/* directory is the root*/
-f_droot:1;
-BITS/* fnode is new and needs fill */
-f_dnew:1;
-BITS/* fnode is assigned to dir */
-f_ddir:1;
-BITS/* filler to avoid a bad bug (feature?) in */
-f_filler:12;/* TC 2.01 */
+BITS f_dmod:1; /* directory has been modified */
+BITS f_droot:1; /* directory is the root*/
+BITS f_dnew:1; /* fnode is new and needs fill */
+BITS f_ddir:1; /* fnode is assigned to dir */
+BITS f_filler:12; /* filler to avoid a bad bug*/
+ /* (feature?) in TC 2.01 */
} dm_flags; /* file flags */
- BYTE dm_attr_fnd; /* found file attribute */
+ UBYTE dm_attr_fnd;/* found file attribute */
time dm_time; /* file time*/
date dm_date; /* file date*/
- LONG dm_size; /* file size*/
- BYTE dm_name[FNAME_SIZE + FEXT_SIZE + 2]; /* file name*/
+ ULONG dm_size;/* file size*/
+ char dm_name[FNAME_SIZE + FEXT_SIZE + 2]; /* file name*/
} dmatch;
-
--- End Message ---
Re: [Freedos-kernel] Re: [Freedos-cvs] mem/source/mem mem.c,1.7,1.8
On Tue, 20 Jul 2004, Arkady V.Belousov wrote:
> 20-éÀÌ-2004 10:09 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> BO> Improved diagnostics (Eric Auer) Adjusted help.
> BO> +++ mem.c 20 Jul 2004 10:09:00 - 1.8
> BO> +while (mlist!=NULL && mlist->seg != lastconseg) {
> ^^^
> BO> +if (mlist->next==NULL) {
> BO> +fatal("UMB Corruption: Chain doesn't reach top of low RAM at
> BO> %dk. Last=0x%x.\n",
> BO> +lastconseg/64, mlist->seg);
> BO> +}
> BO> mlist=mlist->next;
> BO> +}
> BO> +/* should not be reached anymore: */
> BO> +if (mlist->next==NULL)
> -^
> BO> +fatal("Fell of end of memory chain - UMB corruption?\n");
> BO> +
> BO> mlist=mlist->next;
>
> As I already report, "mlist->next==NULL" will never happen, but
> "mlist==NULL" is possible, thus bug with dereferencing NULL is remained.
Did Eric agree with you? He didn't send me an update.
Bart
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] mem/source/mem mem.c,1.7,1.8
Hi!
20-Июл-2004 10:09 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> Improved diagnostics (Eric Auer) Adjusted help.
BO> +++ mem.c 20 Jul 2004 10:09:00 - 1.8
BO> +while (mlist!=NULL && mlist->seg != lastconseg) {
^^^
BO> +if (mlist->next==NULL) {
BO> +fatal("UMB Corruption: Chain doesn't reach top of low RAM at
BO> %dk. Last=0x%x.\n",
BO> +lastconseg/64, mlist->seg);
BO> +}
BO> mlist=mlist->next;
BO> +}
BO> +/* should not be reached anymore: */
BO> +if (mlist->next==NULL)
-^
BO> +fatal("Fell of end of memory chain - UMB corruption?\n");
BO> +
BO> mlist=mlist->next;
As I already report, "mlist->next==NULL" will never happen, but
"mlist==NULL" is possible, thus bug with dereferencing NULL is remained.
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FreeCOM
Hi! At last, Lucho prepares for me executable of FreeCOM from CVS (version 0.82pl3v). Now this edition is shorter (67k instead 95k) and it works with empty environment. Lucho places it on his site, I also may resend this executable for those, who need. Phew. PS: Kenneth, (if and) when you place executable of 2035a (somewhere), don't forget to include into archive fixed FreeCOM. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hi! 20-Июл-2004 10:00 [EMAIL PROTECTED] (tom ehlert) wrote to "Arkady V.Belousov" <[EMAIL PROTECTED]>: >> explicitly developed to ease portability. About uint32_t: good name, but >> DWORD (UDWORD) is more traditional. :) te> the kernel has a 10 year tradition to use ULONG, te> but you aren't going to play by any rule anyway :(( Search accross kernel files: 21 line with "DWORD" in hdr/*.*, 7 lines in kernel/*.c, 6 in kernel/*.h. >> And? For me, it looks as "quick and dirty" hack, may be there is better >> ways for "garbage collection" over near fnodes? te> I agree - it's a damned dirty hack. but I haven't found a way so far te> to do it better - and I *had* to find a solution for this problem. I _not_ say that _you_ made bad work or that you not found solution. I only say, that found _solution_ isn't looks... beauty? nice? consistent? No more, no less. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hello Arkady, BO>> Or ULONG or u32 or uint32_t or uint_least32_t or simply "unsigned long". BO>> These structures aren't portable anyway. What's in a name? > Nothing in C/C++ is portable, this is nature of these languages, which > present only machine specific types. But BYTE/WORD/DWORD types are > explicitly developed to ease portability. About uint32_t: good name, but > DWORD (UDWORD) is more traditional. :) the kernel has a 10 year tradition to use ULONG, but you aren't going to play by any rule anyway :(( >>> PS: Do you see the patch from tom, related to unfreed near fnodes at >>> critical handler? BO>> Yes. > And? For me, it looks as "quick and dirty" hack, may be there is better > ways for "garbage collection" over near fnodes? I agree - it's a damned dirty hack. but I haven't found a way so far to do it better - and I *had* to find a solution for this problem. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hi! 20-Июл-2004 16:01 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: >> AVB> I have the trouble: when I move _TEXT after HMA_TEXT and include into >> AVB> TGROUP (to minimize usage of low memory), BC's kernel behaves wrongly. Do BO> If you try to do that the problem is INIT_TEXT. Because the segment and BO> group are different from _TEXT the compiler generates a far call to _TEXT, BO> say, call 0010:1234. Exeflat or the UPX stub relocate that to BO> call 0070:1234. Oh, God, how I may forget about non-relocatable references? :( BTW, Jibz's EXE2COM beside converting executables without relocations into header-less file, also may convert executables with relocations. For this, EXE2COM add small stub and moves relocation table (in compact form) there. So, in theory, for kernel may be added similar stub (which will work not only at startup, but at each kernel parts relocation), which will process relocation table (for references to moved parts). :) This also removes needing in (main task of) EXEFLAT (except that EXEFLAT beside fixing relocations also preserves boot drive number) and removes needing in _HMARelocationTableStart area (because it will be replaced by relocation table from .EXE header). :) BO> Only with patchobj tricks and stubs you may be able to avoid the low code BO> (as was done with OW before ke2033 or so). Or by merging init and hma BO> text into one segment but then the code by TC is >64K together (surely BO> for FAT32). May be, at last it may be optimized into less than 64k? :) BO> In the end, IMHO, it's just not worth the effort (just use Watcom instead!). Ok... while someone, sometime not implements processing of original relocation table from header instead limited _HMARelocationTableStart. :) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hi! 20-Июл-2004 16:29 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: >> You develop the fnode structures, so should know the better. BO> No, I just changed them. ...but anyway know better, because already "change them". >> Thus, may you yourself fix the bugs in lfnapi.c (where used removed >> f_dmod field instead F_DMOD mask)? BO> Maybe, it's not very urgent Of course. But should be done sometime. The earlier - the better. >> Also, I wish to know: may we remove >> f_cluster_offset field (and use in fatfs.c:map_cluster() stack variable)? BO> We may, but we should not as it would seriously hurt file system BO> performance. f_cluster_offset is a persistent field used to optimize BO> reads and writes. If you do a forward-lseek to a position (changing BO> f_offset), then the only relationship you can count on is between BO> f_cluster and f_cluster_offset, and this enables you to follow the BO> FAT from f_cluster to the present position, instead of having to follow BO> it all the way from the beginning of the file. Ah, yes, I see. As I now understand, f_cluster_offset (not f_offset) is used to remember file position, whereas f_offset used to pass position into map_cluster(), instead using parameter of map_cluster(). What you think, if fnode will contain only f_offset (from which also may be computed the real relative cluster#), and change for f_offset (may be, except 0) will be performed by map_cluster(), which will receive new position through parameter (and store into f_offset after storing the physical cluster number in f_cluster)? (Slightly more and not urgent work to reduce changes of f_offset outside map_cluster(), but this should reduce fnode array size). Also, as induced by Eric: - may be f_flags joined with f_mode (by placing F_DMOD and other such masks into bit 2..3 of f_mode)? And/or, f_mode and f_flags should be declared as UBYTE? - may/should be `static dmatch Dmatch;' in fcbfns.c moved to stack in the FcbFindFirstNext() (as in other functions in fcbfns.c)? - is this bug in dosfns.c:DosGetFree(): /* a passed nc of 0x means: skip free; see FatGetDrvData fcbfns.c */ if (*nc != 0x) *navc = (COUNT) dos_free(dpbp); ? What should be used instead "if (*nc != 0x)"? May be, "if (navc)"? - initdisk.c:LBA_Get_Drive_Parameters(): isn't better to not analyze the .heads and .sectors fields? Isn't better to not switch to StandardBios (but use -1ul instead .totalSect) if .totalSectHigh is nonzero (though, it may be warned anyway)? >> BO> However, when mirroring an RBIL-dictated structure we should use >> BO> ULONG (which is FD kernel speak for a 32 bit unsigned integer, I'm not >> For 32-bit unsigned integers should be used UDWORD type. BO> Or ULONG or u32 or uint32_t or uint_least32_t or simply "unsigned long". BO> These structures aren't portable anyway. What's in a name? Nothing in C/C++ is portable, this is nature of these languages, which present only machine specific types. But BYTE/WORD/DWORD types are explicitly developed to ease portability. About uint32_t: good name, but DWORD (UDWORD) is more traditional. :) >> PS: Do you see the patch from tom, related to unfreed near fnodes at >> critical handler? BO> Yes. And? For me, it looks as "quick and dirty" hack, may be there is better ways for "garbage collection" over near fnodes? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
