Re: [Freedos-kernel] bug in kernel 2035ar
Hi! 23--2004 18:48 [EMAIL PROTECTED] (tom ehlert) wrote to Eduardo Casino [EMAIL PROTECTED]: te downloaded ke2035ar. te just did what I did for 3 years in a row: copy my old CONFIG.BAT --^^ There was changes in config.b. For example, now you may redefine through config.bat your own LINK and LIB. Of course, you should update your config.bat. te saidc:BUILD te and got Compilation was aborted! te congratulations :(( --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: cleanups
Hi! 23--2004 16:09 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: Well... Changes are arrive and arrive... Do you will upload some archive, which may be downloaded and all your changes may be compared with my tree? EA This is EXACTLY what I would want YOU to do! I HAVE NO ONLINE and rely on other peoples (like LUCHO) willingness. EA It would be great if you, EA Arkady, could upload a collection of all patches, plus a big text file EA which tells us exactly which patch fixes / changes / optimizes / comments EA what, All of this is available through Lucho site. As sayed by Lucho, he include into archive docs/news.txt. --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hi!
24--2004 14:37 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO apart from the drawbacks there is another problem:
BO mov bp, [bp + 20] ; store id (in SS:) unless it's NULL
BO or bp, bp
BO jz nostore
BO mov [bp], bx
BO nostore:
if (*id)
*id = r.b.x;
[above code from tom's patch, where he tries to replace asm by C code]
BO The first * in this part is wrong, and also id lives on the stack, but
BO SS!=DS here (!), see the comments elsewhere in nls.c.
Line 114:
COUNT muxLoadPkg(UWORD cp, UWORD cntry)
{
UWORD id; /* on stack, call_nls in int2f.asm takes care of this
* if DS != SS */
BO it would need to be
BO if (id != NULL) /* or if (id) */
BO poke(_SS, id, r.b.x);
Yes. Very ugly. :(
BO returning a long (or a struct with two ints, but I'm not sure if all
BO compilers we use put that in dx:ax)
BC does, TC does, OW does. Don't know about MSVC, but I doubt that it
doesn't.
BO would be another way to avoid this, and save a bit of stack space too.
Hm. You mean, return in DX value of BX instead storing it at *id?
---
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_idG21alloc_id040op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi! 21--2004 23:33 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. end of story. EA Compiler weakness :-P. Caused by language(s) nature (which require to automatically promote integral types in expressions to common base). --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi! 22--2004 21:24 [EMAIL PROTECTED] (tom ehlert) wrote to Eric Auer [EMAIL PROTECTED]: please provide exact code sequence where it DOES return nonsense - and I'll fix it. (we are talking about ke2035 !!) That translates to: Provide a fix and you will have provided a fix. Helpful. te I intended to say (as above, but didn't exactly say it): teprovide some sort of te mov ax,XXX te mov dx,YYY te int 21h -- misbehaviour (wrong return value, crash or just reboot) teand the cavalry is set into march Eric, provide precise scenario for tom. For example: - I have unformatted partition, unimportant which size; - I run WHICHFAT; - I get bla-bla-bla behavior instead bla-bla-bla behavior, as in MS-DOS; - WHICHFAT calls bla-bla-bla functions; on output expected bla-bla-bla, but received bla-bla-bla. and it's better not to touch these disks at all. I vote for: Then you better only use the first 2 TB. te I vote for: wait till 2TB disks arrive. see. possibly fix bugs. te THEN remove this. _Sometime_, better to prevent such bugfixing, especially because CHS access is only one possible way, how to handle strange geometry, and it is not the best (even as compromise between LBA and no disk). Track wrap protection and DMA wrap protection should be turned off (maybe add a SYS CONFIG variable!) for harddisks. te I measured - it's irrelevant. Irrelevant = doesn't changes speed? --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch
Hi!
- small code cleanup (generated code not changed).
---BeginMessage---
diff -ruNp old/kernel/dosfns.c new/kernel/dosfns.c
--- old/kernel/dosfns.c 2004-07-20 17:57:38.0 +
+++ new/kernel/dosfns.c 2004-07-24 21:22:54.0 +
@@ -308,19 +308,14 @@ long DosRWSft(int sft_idx, size_t n, voi
}
}
-#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)
+int SftSeek(int sft_idx, LONG new_pos, unsigned mode)
{
sft FAR *s = idx_to_sft(sft_idx);
if (FP_OFF(s) == (size_t) -1)
return DE_INVLDHNDL;
/* Test for invalid mode*/
- if ((unsigned)mode SEEK_END) /* 2 */
+ if (mode SEEK_END) /* 2 */
return DE_INVLDFUNC;
lpCurSft = s;
@@ -1025,8 +1020,7 @@ STATIC int pop_dmp(int rc, dmatch FAR *
return rc;
}
-/* !!! `name' should be `const char FAR*' --avb */
-COUNT DosFindFirst(UCOUNT attr, BYTE FAR * name)
+COUNT DosFindFirst(UCOUNT attr, const char FAR * name)
{
dmatch FAR *save_dta = dta;
int rc = truename(name, PriPathName,
diff -ruNp old/kernel/proto.h new/kernel/proto.h
--- old/kernel/proto.h 2004-07-24 22:04:32.0 +
+++ new/kernel/proto.h 2004-07-24 22:04:26.0 +
@@ -77,11 +77,16 @@ long cooked_write(struct dhdr FAR **pdev
sft FAR *get_sft(UCOUNT);
/* dosfns.c */
+
+#define SEEK_SET 0
+#define SEEK_CUR 1
+#define SEEK_END 2
+
const char FAR *get_root(const char FAR *);
BOOL check_break(void);
UCOUNT GenericReadSft(sft far * sftp, UCOUNT n, void FAR * bp,
COUNT * err, BOOL force_binary);
-COUNT SftSeek(int sft_idx, LONG new_pos, COUNT mode);
+COUNT SftSeek(int sft_idx, LONG new_pos, unsigned mode);
/*COUNT DosRead(COUNT hndl, UCOUNT n, BYTE FAR * bp, COUNT FAR * err); */
void BinarySftIO(int sft_idx, void *bp, int mode);
#define BinaryIO(hndl, bp, mode) BinarySftIO(get_sft_idx(hndl), bp, mode)
@@ -101,7 +106,7 @@ BOOL DosGetFree(UBYTE drive, UWORD * spc
UWORD * bps, UWORD * nc);
COUNT DosGetCuDir(UBYTE drive, BYTE FAR * s);
COUNT DosChangeDir(BYTE FAR * s);
-COUNT DosFindFirst(UCOUNT attr, BYTE FAR * name);
+COUNT DosFindFirst(UCOUNT attr, const char FAR * name);
COUNT DosFindNext(void);
COUNT DosGetFtime(COUNT hndl, date * dp, time * tp);
COUNT DosSetFtimeSft(int sft_idx, date dp, time tp);
@@ -374,7 +379,6 @@ void child_psp(seg_t para, seg_t cur_psp
void return_user(void);
COUNT DosExec(COUNT mode, exec_blk FAR * ep, BYTE FAR * lp);
ULONG SftGetFsize(int sft_idx);
-VOID InitPSP(VOID);
#ifdef __WATCOMC__
# pragma aux return_user aborts
#endif
---End Message---
[Freedos-kernel] Re: patch: dosfns.c fcbfns.c inthndlr.c proto.h
Hi Arkady! Your patch is MUCH too long. This is my (first) try to bugfix wrong INT21/1B, INT21/1C and INT21/36. Sorry, tom, but there more than 1-2 lines of diff, and I doubt that this diff may be (noticeably) reduced. - bugfix: DosGetFree(): *navc was accessed (read and write) without checking if navc!=NULL; instead navc!=NULL was used *nc!=0x. - bugfix: FatGetDrvData(): was changed UWORD *spc, but INT21/1B and INT21/1C should change only AL, not AX. ? FatGetDrvData(): when get_dpb()==NULL, as value for media ID was used high byte of *spc (sectors_per_cluster), but it always zero. - static Dmatch moved nearer to FcbFindFirstNext() and added comment from tom. - bugfix: INT21/1B, INT21/1C: FatGetDrvData() now called with lr.AL, not AX. I am trying to summarize it: - you moved rg[4] more towards inside (optimizes better) - you did something with dpbp - you removed UWORD * spc argument from DosGetFree everywhere - you replaced (navc != NULL) by (navc) everywhere + spc = dpbp-dpb_clsmask + 1; ... you replaced access to *spc by access to spc everywhere, as it no longer is accessed through a pointer argument to DosGetFree. Instead, you made it the return value of DosGetFree, I think, and -1 now means FALSE everywhere. - if (*nc != 0x) -*navc = (COUNT) dos_free(dpbp); + if (navc) +*navc = (UWORD) dos_free(dpbp); That really fixes something I think. In fcbfns.c, in FatGetDrvData, you changed: - mdb = *spc 8; +static UBYTE mdb = 0; In calling FatGetDrvData the return value is no longer p = ... but it now is UBYTE FAR *p = ... which looks like a real change, possibly useful ;-). -p = FatGetDrvData(lr.DL, lr.AX, lr.CX, lr.DX); + UBYTE FAR *p = FatGetDrvData(lr.DL, lr.AL, lr.CX, lr.DX); - DosGetFree(lr.DL, lr.AX, lr.BX, lr.CX, lr.DX); + lr.AX = DosGetFree(lr.DL, lr.BX, lr.CX, lr.DX); You also moved get_cds1() to some completely different location and changed some argument types and names, e.g. FatGetDrvData UWORD * spc got replaced by UBYTE * pspc. And of course you changed formatting, e.g. merging several consecutive if into one, using only a bare minimum of parentheses, which probably means that the formatting change does not improve readability. So what got actually fixed? I think the *spc handling in several aspects and the (*nc != 0x) which you replaced by (navc), or in other words by (navc != NULL). Not sure if the movement pointered argument - return value actually means a fix, too. May I summarize the most important part of the fix as: - if (*nc != 0x) + if (navc) ...!? Sorry, tom, but there more than 1-2 lines of diff, and I doubt that this diff may be (noticeably) reduced. I doubt that you did try to keep the diff short AT ALL. 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: It's a difficult question. Essentially there are two ways we can go: 1. if the kernel very carefully minimizes stack usage on the code path taken and NLSFUNC itself only uses a couple bytes of stack in between it's possible to just do it. or 2. nlsfunc would have to copy anything in between ss:sp and ss:920 (_disk_api_tos, that's the top of the stack used here in any DOS = 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call DOS. Then after the call adjust the stack pointer, then swap it back, then return. Just curious, what about a 3rd possibility: implement the 2f12xx calls as documented in RBIL? For example, 2f1228: sets user stack frame pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores frame pointer. (This is the what, my problem is how :) The user stack frame pointer is poined to by a global variable user_r in the FreeDOS kernel. It points to the user stack which is yet another stack. It sits in the SDA at 264hDWORD pointer to stack frame containing user registers on INT 21 What normally happens is that: 1. user calls int21/ah=42 2. registers are pushed on the stack (entry.asm) 3. ss:sp stored in user_r 4. ss:sp moves to DOS stack 5. DOS does the lseek using the values pushed in 2. 6. DOS updates the registers on the user stack Essentially the RBIL comments says that, in MSDOS, 2f1228 changes user_r to point to a dummy place, moves the value of BP to the AX-slot in the dummy user_r stack, calls steps 4-6, restores user_r, and returns. In FreeDOS that would mean something like this: case 0x28: old_user_r = user_r; user_r = tempplace; user_r-AX = r.BP; int21_service(user_r); user_r = old_user_r; break; This has nothing to do with switching kernel stacks, in fact if FreeDOS would do things this way (instead of calling DosSeek directly) it would use even more stack space. This all goes to say that RBIL is a strange place, sometimes it doesn't report much at all (about error codes for instance), and sometimes it reports about such obscure implementation details. 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
