Re: [Freedos-kernel] kernel progress
Hi! 28--2004 14:11 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: I just reproduce MS-DOS behavior. Also, I myself found that skipping all remaining questions (including ?) is useful. Though, later this behavior may be changed (and documented in config.txt!). A BUT, IMHO the key for that should not be Esc but something completely A different, like some other function key. Agreed. I myself also feel that using Esc for ALLYES is somewhat misleading. But Esc is as in MS-DOS and I introduce (similar) F8. Unfortunately, I don't know which key may be assigned to ALLNO. :( O! What you say about this: ?device=himem.sys[Y/n/Esc=all N/F8=all Y/F5=skip all] Of course, Esc should answer N only for lines with ?. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] default drive and CDS
Hello Arkady, In kernel often used constructions, similar to next: if (get_cds(drv ? drv - 1 : default_drive) == NULL) te in which case 'often' is 2 Ok, 2. But non-zero. In any case there will be useful to introduce get_cds1(), which will call get_cds(drv ? drv - 1 : default_drive) (because there is much more than 2 such instances). in any case, FreeDOS kernel is GPL, so you may do whatever you want. just another example of arkady'fying a project. unfortunately, you drive former developers away - forever. te so I think you are wasting our time. _If_ you don't know the answer, simply don't answer. This your letter contains no useful information. :( only useful questions can get useful answers. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
tom ehlert schreef: - when tracing, Esc now turns off asks for following lines with ? and assumes Y for all; F8 now behaves similar to Esc. I disagree. Esc turns of F8 'single stepping', nothing else. so if pressed ESC, then everything except a command?=value is auto-executed? Arkady, define similar (similar behaviour) please. You mean identical ? AFAIK, the only reason for INSTALL= to exist is, that programs will be INSTALL'ed without environment, and save a few unnecessary environments, else you could load it through autoexec.bat as well. You guys are the experts here. But Lucho showed the use of INSTALL= (and SET) commands, when using his ROMDSK (space is *very* precious there, thus no autoexec.bat). --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
Hi! 27--2004 20:03 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: - when tracing, Esc now turns off asks for following lines with ? and assumes Y for all; F8 now behaves similar to Esc. I disagree. Esc turns of F8 'single stepping', nothing else. BB so if pressed ESC, then everything except a command?=value is BB auto-executed? Now - yes. As in MS-DOS. BB Arkady, define similar (similar behaviour) please. You mean identical ? Yes. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: nls.c
On Fri, 25 Jun 2004, Eduardo Casino wrote:
Trivial patch. Pass correct values for codepage and country from DOS-38
and DOS-65-XX functions to MUX-14 functions.
I would actually suggest the following function, as searchPackage is to
resolve the default values as well; otherwise your patch breaks the
possibility of non-direct (MUX-only) country data, which in turn breaks
the whole current NLS design, which would make it better to replace all
the code. Latter would be better, I guess, anyway.
COUNT DosGetData(int subfct, UWORD cp, UWORD cntry, UWORD bufsize,
VOID FAR * buf)
{
struct nlsPackage FAR *nls; /* NLS package to use to return the info
from */
log((NLS: GetData(): subfct=%x, cp=%u, cntry=%u, bufsize=%u\n,
subfct, cp, cntry, bufsize));
if (!buf || !bufsize)
return DE_INVLDDATA;
if (subfct == 0) /* Currently not supported */
return DE_INVLDFUNC;
/* nls := NLS package of cntry/codepage */
if ((nls = searchPackage(cp, cntry)) != NULL) {
/* matching NLS package found */
if((nls-flags NLS_FLAG_DIRECT_GETDATA) != 0)
/* Direct access to the data */
return nlsGetData(nls, subfct, buf, bufsize);
cp = nls-cp;
cntry = nls-cntry;
}
/* If the NLS pkg is not loaded into memory or the
direct-access flag is disabled, the request must
be passed through MUX */
return (subfct == NLS_DOS_38)
? mux38(cp, cntry, bufsize, buf)
: mux65(subfct, cp, cntry, bufsize, buf);
}
--
Steffen Kaiser
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: nls.c
El vie, 25-06-2004 a las 08:42, Steffen Kaiser escribió: I would actually suggest the following function, as searchPackage is to resolve the default values as well; otherwise your patch breaks the possibility of non-direct (MUX-only) country data, which in turn breaks the whole current NLS design, which would make it better to replace all the code. Thanks. This looks much better, indeed. I assume that you are fixing it yourself, aren't you? Or do you want me to generate the modified patch? Eduardo. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: nls.c
Hi! 25--2004 08:42 [EMAIL PROTECTED] (Steffen Kaiser) wrote to [EMAIL PROTECTED] [EMAIL PROTECTED]: Trivial patch. Pass correct values for codepage and country from DOS-38 and DOS-65-XX functions to MUX-14 functions. SK I would actually suggest the following function, as searchPackage is to I add this into my patches: nls.c - bugfix: nls.c: DosGetData(): (Eduardo Casino, Steffen Kaiser) NULL pointer was addressed when searchPackage returns NULL. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] VERSION= behavior
Hello Arkady, BTW, Eric says, that RBIL describes INT2F/122F functions, which (also) sets returned DOS version. INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN AX = 122Fh DX = DOS version number (h = return true DOS version) have you ever seen DOS 4.x (not 4.0+) ? AFAIR, this was a TASK specific value, and it returns some magic field from PSP. Currently FD not implements this functio (says error for it on screen), but implements (similar) INT21/33FC. Should I _re_define INT21/33FC as INT2F/122F? no. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Best regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: inthndlr.c
Hello Eduardo,
I'm implementing NLSFUNC for FreeDOS and I've found that many (most) of
the needed MUX functions are missing.
This patch implements functions 2F1226h to 2F1229h. This, together with
my previous nls.c patch, allowed me to make a first working
implementation of NLSFUNC's int 2F1404h, but the patch looks so simple
that I must have done something wrong :) so, kernel guys, please, have
a look at it. It is mainly cut'n'paste from int21_service()
a)
why do you need int2f/12 in the first first place ?
are you really executing this from inside KERNEL ?
do you really need to use internal functions ?
if YES, you will probably greatly overrun the kernels 384 byte stack,
which might become a problem.
if NO, why don't you use int21 functions ?
b) lseek(0x1) will fail due to fall from locng_check into
shortcheck.
tom
Eduardo.
diff -uNrp ke2035.orig/kernel/inthndlr.c ke2035/kernel/inthndlr.c
--- ke2035.orig/kernel/inthndlr.c 2004-06-24 22:41:20.0 +0200
+++ ke2035/kernel/inthndlr.c 2004-06-24 22:41:09.0 +0200
@@ -1656,6 +1656,9 @@ struct int2f12regs {
*/
VOID ASMCFUNC int2F_12_handler(struct int2f12regs r)
{
+ COUNT rc;
+ long lrc;
+
if (r.AH == 0x4a)
{
size_t size = 0, offs = 0x;
@@ -1869,6 +1875,42 @@ VOID ASMCFUNC int2F_12_handler(struct in
r.CX = fstrlen(MK_FP(r.DS, r.SI)) + 1;
break;
+case 0x26: /* open file */
+ r.FLAGS = ~FLG_CARRY;
+ CritErrCode = SUCCESS;
+ lrc = DosOpen(MK_FP(r.DS, r.DX), O_LEGACY | O_OPEN | r.CL, 0);
+ goto long_check;
+
+case 0x27: /* close file */
+ r.FLAGS = ~FLG_CARRY;
+ CritErrCode = SUCCESS;
+ rc = DosClose(r.BX);
+ goto short_check;
+
+case 0x28: /* move file pointer */
+ r.FLAGS = ~FLG_CARRY;
+ CritErrCode = SUCCESS;
+ r.BP = 0x00ff;
+ if (r.BP 2)
+goto error_invalid;
+ lrc = DosSeek(r.BX, (LONG)ULONG) (r.CX)) 16) | r.DX),
r.BP);
+ if (lrc == -1)
+ {
+lrc = DE_INVLDHNDL;
+ }
+ else
+ {
+r.DX = (UWORD)(lrc 16);
+lrc = (UWORD) lrc;
+ }
+ goto long_check;
+
+case 0x29: /* read from file */
+ r.FLAGS = ~FLG_CARRY;
+ CritErrCode = SUCCESS;
+ lrc = DosRead(r.BX, r.CX, MK_FP(r.DS, r.DX));
+ goto long_check;
+
case 0x2a: /* Set FastOpen but does nothing. */
r.FLAGS = ~FLG_CARRY;
@@ -1897,6 +1939,26 @@ VOID ASMCFUNC int2F_12_handler(struct in
r.FLAGS |= FLG_CARRY;
}
}
+ goto real_exit;
+long_check:
+ if (lrc = SUCCESS)
+ {
+r.AX = (UWORD)lrc;
+goto real_exit;
+ }
+ rc = (int)lrc;
+short_check:
+ if (rc SUCCESS)
+goto error_exit;
+ goto real_exit;
+error_invalid:
+ rc = DE_INVLDFUNC;
+error_exit:
+ r.AX = -rc;
+ if (CritErrCode == SUCCESS)
+CritErrCode = r.AX; /* Maybe set */
+ r.FLAGS |= FLG_CARRY;
+real_exit:;
}
/*
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
--
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] VERSION= issue
Hello Arkady, Eric Auer suggests, that VERSION= should change os_setver_m*, not os_m*. What you think? Is there is bug in current FD and Eric's suggestion is patch for this? seems to be a bug indeed. seems noone is using version=X.Y ;) tom --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] VERSION= issue
Hi! 25--2004 20:15 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: Eric Auer suggests, that VERSION= should change os_setver_m*, not os_m*. What you think? Is there is bug in current FD and Eric's suggestion is patch for this? te seems to be a bug indeed. Ok, fix right now. te seems noone is using version=X.Y ;) I use, because was try to debug INSTALL= processing (to be precise: to be able dump PSP and environment). --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: inthndlr.c
Hi Tom, a) why do you need int2f/12 in the first first place ? are you really executing this from inside KERNEL ? do you really need to use internal functions ? Yes. NLSFUNC implements kernel extensions to access NLS data from an external file (namely COUNTRY.SYS) and these extensions are called from inside the kernel (int 21/65, int 21/38) if YES, you will probably greatly overrun the kernels 384 byte stack, which might become a problem. OK. How do I setup a different stack for these functions? b) lseek(0x1) will fail due to fall from locng_check into shortcheck. Then we have a real problem, because this was copied from the int 21/42 implementation. Eduardo. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CONFIG.C ANNOYANCE
Hi! 24--2004 19:36 Arkady V.Belousov wrote to [EMAIL PROTECTED]: AVB My near TODO is to: AVB - detect redefinition of env variables (and replace definition). AVB - add environment before each INSTALL=. BTW, forget to mention. Some years ago I report about BUG in ChildEnv(), which wrongly handles empty environment. And, yes, this is easy to see: run some program through INSTALL= (in current FD) and review its environment. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] VERSION= issue
Hi! 24--2004 18:35 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: MS-DEBUG doesn't runs from FD because Incorrect DOS version. Setting required through VERSION= doesn't helps. Analyzing of inthndlr.c shows, that os_major and os_minor returned only through INT21/3306, for INT21/30 used os_setver_*. Is this bug (in config.c:sysVersion(), which not sets os_setver_*)? te RBIL: te INT 21 - DOS 5+ - GET TRUE VERSION NUMBER te AX = 3306h te the only bug here: FD 21/3306 isn't reentrant te BTW: debug call int21/30 only. tom, I understand that debug call INT21/30 and this is why in current FD VERSION= doesn't helps to run it. I ask: is there are some hidden reasons to not _initialize_ os_setver_major and os_setver_minor for VERSION= in config.c:sysVersion() to same values, as os_major and os_minor? PS: BTW, main.c:init_kernel() initializes both os_m* and os_setver_*; even with VERSION= FreeCOM VER/R returns 7.10. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] latest kernel
Arkady V.Belousov [EMAIL PROTECTED] writes: Lucho tests kernel with all my patches and says that he satisfied. Updated romd-bin.rar kernel package available on his site. What is his site? Thanks! - Pat --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] config.c: progress
Arkady V.Belousov wrote: Hi! Arkady, I'll try to compile your kernel tonight, as I experienced some hardware upgrade glitches the last 2 days. as someone asked (I lost about 35 emails) : Lucho's site is at: http://linux.tu-varna.acad.bg/~lig/ it contains the Romdsk stuff and the UDMA DOS-driver. Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
Hi! 18--2004 18:27 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD provided I will work on the config processing. I not send any patch here. Reason: there too many changes - so, I should send one _big_ patch or send _many_ smaller patches. I fear, this is not acceptable here. KJD That's fine, it doesn't matter to me if its one big, several smaller, or KJD even just the changed file. I may send you my edition of config.c (private, I suggest?), but it not the last edition (I continue to work on it). I see, you miss some my changes (for example, fl_diskchanged epilog) KJD please be more specific, ? KJD for example I changed floppy.asm patch 3 to maintain the same size Same size of what? KJD and return values as the original logic, as Of course, I check validness of change. KJD I did not see a reason to make the code longer ? My code not longer. KJD and return 0x00FF instead of 0x (-1). Because other functions do this (return one byte with zero AH)! I just add consistency. and add own comments. For example: KJD yes, I viewed yours, the original, RBIL, and the code and selected KJD the one that seemed the most clear, being more verbose if necessary. Hm, I look at RBIL. Looks, like there is another ambiguite (or even wrong) description. :( PS: There are also other re-changes in compare to original and my edition. For example, I describe `drive' parameter for all functions (as in dsk.c) as UBYTE (this gets better code) and return type as `int' - in your edition this is no so. Also, I think, explaining in comments for sbb al,al that Al=-CF is not good. This is same, as write next: int i = ... i++; /* increment i */ (BTW, you preserve comment in mov ah,0 ; zero out ah). Also, you preserve wrong comment cylinder number (lo only if hard) - this is complete cylinder number, not its lo part. Also, count to read/write is wrong comment, because there is code for format and verify (same for fl_lba_readwrite()). Also, you remain (Zero transfer count) and force into 255 count, whereas AL (AL only, AH cleared!) returns error code, not transfer count. PPS: Also, there are cosmetic remarks (from me :): in some places you preserve my tabulations (though, before some comments you lost one - see, for example, mov ah,18h), in other places you preserve trailing spaces (even on empty lines)... --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
...
I may send you my edition of config.c (private, I suggest?), but it not
the last edition (I continue to work on it).
please do
...
and add own comments. For example:
KJD yes, I viewed yours, the original, RBIL, and the code and selected
KJD the one that seemed the most clear, being more verbose if necessary.
Hm, I look at RBIL. Looks, like there is another ambiguite (or even
wrong) description. :(
In the future I will be more careful and try to validate descriptions
with other resources.
PS: There are also other re-changes in compare to original and my edition.
For example, I describe `drive' parameter for all functions (as in dsk.c) as
UBYTE (this gets better code) and return type as `int' - in your edition
While the drive parameter is an unsigned byte, it is actually passed in
as a word, and the prototypes in dsk.c at present still indicate this.
So instead of using UBTYE in one place (floppy.asm) and WORD in another
(dsk.c), I maintained the use of WORD. No code is effected, as these
are strictly changes to comments. When I apply your dsk.c patch 10,
which does change the prototypes, I will change floppy.asm to match.
this is no so. Also, I think, explaining in comments for sbb al,al that
Al=-CF is not good. This is same, as write next:
int i = ...
i++; /* increment i */
My comment isn't AL=-CF it is AL=-CF={-1,0}, the comment is
saying that after the sbb call, AL is either -1 or 0. The -CF simply
clarifies that only carry determines the actual value.
(BTW, you preserve comment in mov ah,0 ; zero out ah). Also, you preserve
sure its an obvious comment, but how does it adversely effect anything?
wrong comment cylinder number (lo only if hard) - this is complete
cylinder number, not its lo part. Also, count to read/write is wrong
corrected
comment, because there is code for format and verify (same for
how about 'count of sectors to read/write/...'
fl_lba_readwrite()). Also, you remain (Zero transfer count) and force
into 255 count, whereas AL (AL only, AH cleared!) returns error code, not
transfer count.
ok, adjusted, I read this comment as extending al into ax without sign
extension.
PPS: Also, there are cosmetic remarks (from me :): in some places you
preserve my tabulations (though, before some comments you lost one - see,
for example, mov ah,18h), in other places you preserve trailing spaces
(even on empty lines)...
While I will commit some, I prefer to not make whitespace only changes.
it also depends on how I apply a given patch.
Jeremy
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
Hi!
19--2004 15:41 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to
[EMAIL PROTECTED]:
I may send you my edition of config.c (private, I suggest?), but it not
KJD please do
Done. See archive with config.c, portab.h (from which used new macro)
and makefiles (which also pass for compiler path to its include files - new
portab.h uses compiler's limits.h).
KJD are strictly changes to comments. When I apply your dsk.c patch 10,
KJD which does change the prototypes, I will change floppy.asm to match.
Why change prototype lines twice? As I understand, this generates extra
unnecessary entries in CVS.
this is no so. Also, I think, explaining in comments for sbb al,al that
Al=-CF is not good. This is same, as write next:
int i = ...
i++; /* increment i */
KJD My comment isn't AL=-CF it is AL=-CF={-1,0}, the comment is
KJD saying that after the sbb call, AL is either -1 or 0.
But this is what sbb al,al mean and do. I think, comment should
contain more high-level explanations, than repeating description from
Instruction Set Manual. For example:
sbb al,al ; CF=0 (disk has not changed)
jnc ret_AH_0; ...return 0
cmp ah,6; ah!=6 (error)
jne ret_AH_0; ...return 0xFF
(BTW, you preserve comment in mov ah,0 ; zero out ah). Also, you preserve
KJD sure its an obvious comment, but how does it adversely effect anything?
It not affect anything, but this comment was not present in my patch.
This mean, you copy it from old source.
comment, because there is code for format and verify (same for
KJD how about 'count of sectors to read/write/...'
What bad in plain number of sectors?
fl_lba_readwrite()). Also, you remain (Zero transfer count) and force
into 255 count, whereas AL (AL only, AH cleared!) returns error code, not
transfer count.
KJD ok, adjusted, I read this comment as extending al into ax without sign
KJD extension.
Ok.
PPS: Also, there are cosmetic remarks (from me :): in some places you
preserve my tabulations (though, before some comments you lost one - see,
for example, mov ah,18h), in other places you preserve trailing spaces
(even on empty lines)...
KJD While I will commit some, I prefer to not make whitespace only changes.
KJD it also depends on how I apply a given patch.
When you change line, this is wise to fix, for example, spacings. But
your changes are inconsistent: in one case you preserve spaces, in other
case you replace spaces by tabs, in third case I see wrong shifting:
__O\_/_\_/O__
mov al, 1 ; set change occurred
fl_dc: cbw ; extend AL into AX, AX={1,0,-1}
ret ; note: AH=0 on no change, AL set above
[...]
pushbx ; restore stack
mov ah,17h ; floppy set disk type for format
_
O/~\ /~\O
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
Hi! 18--2004 03:12 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD I have gone through Arkady's floppy patchset (is there a 5 of 5?). There was 4 of 5. Last patch I omit, because it was cosmetic. Ot the other side, you may get complete floppy.asm patch (all in one) in previous letters. KJD This weekend I intend to finish processing his dsk.c patchset KJD (which includes Lucho's rewording patch), and once a patch is KJD provided I will work on the config processing. I not send any patch here. Reason: there too many changes - so, I should send one _big_ patch or send _many_ smaller patches. I fear, this is not acceptable here. KJD As I commit updates, please refer to sourceforge for source, but Is kernel.tgz will be updated? KJD Please feel free to comment and thank you for the patches! KJD CVS: drivers/floppy.asm hdr/version.h I see, you miss some my changes (for example, fl_diskchanged epilog) and add own comments. For example: + pop dx ; drive, (DL only, bit 7 set resets both floppy hd) ---^^... This is wrong addition: of course, BIOS enumerates hard disks as 80h-ffh (with bit 7 set), bit 7 not relates to reseting both floppy and hd, there will be reset disk, which number is in DL and only it. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
Arkady V.Belousov wrote: Hi! 18--2004 03:12 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD I have gone through Arkady's floppy patchset (is there a 5 of 5?). There was 4 of 5. Last patch I omit, because it was cosmetic. Ot the other side, you may get complete floppy.asm patch (all in one) in previous letters. Ok. Thanks, just wanted to make sure I didn't somehow overlook it on sourceforge. KJD This weekend I intend to finish processing his dsk.c patchset KJD (which includes Lucho's rewording patch), and once a patch is KJD provided I will work on the config processing. I not send any patch here. Reason: there too many changes - so, I should send one _big_ patch or send _many_ smaller patches. I fear, this is not acceptable here. That's fine, it doesn't matter to me if its one big, several smaller, or even just the changed file. KJD As I commit updates, please refer to sourceforge for source, but Is kernel.tgz will be updated? Should be. KJD Please feel free to comment and thank you for the patches! KJD CVS: drivers/floppy.asm hdr/version.h I see, you miss some my changes (for example, fl_diskchanged epilog) please be more specific, for example I changed floppy.asm patch 3 to maintain the same size and return values as the original logic, as I did not see a reason to make the code longer and return 0x00FF instead of 0x (-1). see http://www.fdos.org/kernel/2035a/arkady/test.asm for the three variations (mine, yours, the original). and add own comments. For example: yes, I viewed yours, the original, RBIL, and the code and selected the one that seemed the most clear, being more verbose if necessary. + pop dx ; drive, (DL only, bit 7 set resets both floppy hd) ---^^... This is wrong addition: of course, BIOS enumerates hard disks as 80h-ffh (with bit 7 set), bit 7 not relates to reseting both floppy and hd, there will be reset disk, which number is in DL and only it. Ok, I will remove it. It was taken from RBIL, and I added as it looked like a really weird quirk to be aware of and research a bit further; along with determing if we actually called any of the floppy functions with a disk number corresponding to a hard drive, as RBIL indicated for several of the calls we use about problems with some buggy BIOSes if a value greater than 0x7Fh was use (ie if drive number refers to a hard drive). Jeremy --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [patch] #1758 - fix incorrect AskSingleLine function
Arkady V.Belousov schreef: - 123? present and statement not from selected menu? Skip. - ! present? Don't skip. - ? present or single step? Ask. Your proposal changes behavior: now it will look so: - 123? present and statement not from selected menu? Skip. - ? present? Ask. - single step and not ! present? Ask. I wanted 0123?!ECHO?=DUMMY.SYS also to be asked (because it contains ?= part) in current FreeDOS kernel, the ?= part is ignored because ! is present. cases 4 and 8 go wrong here (auto-executed..) echo=1// only ask when F8 echo?=2 // always ask !echo=3 // should never ask !echo?=4 // should always ask, even if F8 012?echo=5// only ask when F8 (and ofcourse menu 1, 2,or 3 selected) 012?echo?=6 // always ask 012?!echo=7 // never ask 012?!echo?=8 // should always ask, even if F8 ANY ?= should raise the ASK-question, even if ! is present. Eric optimized the function a bit :) Well... I hardly rework config.c and fix many bugs (most of them are not check input validness - for example, break=offk accepted as on). Also I add above your changes. If you wish/can/may, I send you my config.c for testing. I'll gladly receive your config.c please send entire file, not a patch. (I haven't learned using DIFF/PATCH yet, but learned compiling a bit) Bernd --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [patch] #1758 - fix incorrect AskSingleLine function
Hi! 13--2004 19:39 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: BB Eric and I have been working a few hours on a patch to correct the BB ask-user-to-execute-config.sys-line algorythm. BB essentially (config.c, line 806 I think): BB/* !device= never ask / device?= always ask / device= ask if singleStep */ BB/* ! does override singleStep but not ?, so !device?= will ask... */ As I understand, currently behavior is this: - 123? present and statement not from selected menu? Skip. - ! present? Don't skip. - ? present or single step? Ask. Your proposal changes behavior: now it will look so: - 123? present and statement not from selected menu? Skip. - ? present? Ask. - single step and not ! present? Ask. I think, this is valid. BBif (! ( (singleStep !DontAskThisSingleCommand) || BB(askThisSingleCommand) ) ) BB return FALSE; /* do not skip, and do not ask either */ This is identical to (simpler): if ((!singleStep || DontAskThisSingleCommand) !askThisSingleCommand) return FALSE; /* do not skip, and do not ask either */ but I think this better will look so: if (!(askThisSingleCommand || /* ? */ singleStep !DontAskThisSingleCommand)) /* not ! */ return FALSE; /* do not skip, and do not ask either */ Well... I hardly rework config.c and fix many bugs (most of them are not check input validness - for example, break=offk accepted as on). Also I add above your changes. If you wish/can/may, I send you my config.c for testing. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Arkady V.Belousov escribi: Hi! 9--2004 23:26 [EMAIL PROTECTED] (Aitor Santamar?a Merino) wrote to [EMAIL PROTECTED]: MS-DOS is a 16-bit OS. ASM io.sys and msdos.sys are 16-bit, emm386.exe is 32-bit. But emm386 is not part of kernel. But it is part of MS-DOS. It not breaks MS-DOS compatability, there is only breakage with alone configuration of alone program coder. ASM For me the key testing is to check wether MS-DOS kernel does this. If it ASM does, then it is a clear compatibility breakage. If in some configuration (in MS-DOS) you load some driver and you will not load this driver under FD and some program without this driver will behave differently, then this is _not_ and issue of FD. ? ASM Until it is tested by someone, I'd say that the bug shouldn't be closed ASM or set as WONTFIX or such (no matter how much we wish it to be true). Right now I run (16-bit) MS-DEBUG and inspect registers (with help of pushad instruction, as offered by Eric): some high parts are nonzero (for example, EBX and EDX). Ok, if this is so... I just wonder how that program that relies on having high parts cleared has ever worked under MS-DOS. Aitor --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Re: Kernel bug parade / moving on
Hi! 9--2004 03:27 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA The bug submitter for clear high parts of 32 bit registers on exec EA claims to have experienced actual problems because of one program leaving EA values in registers and another program assuming those parts to be 0. Some drivers (say, himem) on machine, where was written those garbage-dependent program, clear high parts of registers. How this relates to DOS? EA However, he does not tell anything about which program is affected. We have proverb (fairy tale, to be precise): go don't know where, get don't know what. Same here: we don't know, which program affected, don't know what it expected (and why!), how these expectations was reached (DOS? drivers?) - and we should achive these expectations?! EA If it would be DOS4GW then we would be really motivated :-). ...to built DOS4GW into kernel? You joke. How DOS should deal with third and fourth drives - I don't know, but I suggest, this is possible only through driver.sys (there you point physical drive number 0..127, and it traps next logical drive letter). EA You just said that BIOS would handle it and that equipment list can handle EA up to four drives as well. So why would we need a driver sys for it? And I Because MS-DOS need it. From first versions there was reserved only two letters for floppy drivers, and we can/should not change this. Especially, programs with two controllers very rare and there are not hard to use additional driver (and/or config.sys statement) for supporting those additional hardware. EA do indeed suggest to make driver sys a kernel builtin if we need it at all. This is not bug report, but wish. Also, this wish about _additional feature_, not about change for behavior. (Changing order of drive letters assignment _is_ feature with changed behavior). Ie. you offer to integrate help, tutor and training subsystem into kernel? Currently DOS ignores DOS=UMB statement, if there are no UMBs available. I think, extra messages like NO UPPER MEMORY AVAILABLE FOR YOUR DOS=UMB STATEMENT makes only uncomfortable noise. EA This is partially true. This is completely true. Me always annoys messages from NDOS' LH command about missing UMB. Note: there may be common configs for different environments, where one environment contains UMBs, other - not. EA Better error messages are sometimes good but a whole EA tutor system would mean noise. By the way, does the kernel suppress showing EA more than one UMB-warning if you have more than one DEVICEHIGH/INSTALLHIGH EA now? Don't know yet, config.c is not processed by me yet. EA Bernd filed a bug report / feature request to suppress the extra noise. Manifest from QEMM EA This reminds me that some QEMM versions spoil APMDOS / ADV:... mode of EA FDAPM (i.e. it saves no energy if QEMM loaded). If you have QEMM yourself, EA feel free to test whether your version is affected in combination with your EA CPU and BIOS. My (old) computer have no APM support. EA Manifest was a cool piece of software at the time. Yes, nice. EA About bug 1789, kernel confused by PKZIP-builtin format command: I think EA the LBA-... error message happened at the beginning and the end of the EA process. But please do read the whole bugzilla entry and contact the bug EA reporter to learn more, I do not use PKZIP (I use Info-ZIP ZIP / UNZIP). Which URL? --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Eric Auer escribió:
Hi Arkady!
(Clear high parts of 32bit regs...)
How this relates to DOS?
MS DOS basically had no 386 stuff at all (except EMM386). In FreeDOS,
however, people run 386 aware programs more often. Those leave non-zero
values in 32 bit registers when they exit, and the next program which you
start...
Whatever. You are right. Very bad programming practice to expect the high
parts of the 32 bit registers to have some value. I close that bug report
then.
Lawrence comments that this only affected an old version of the
GRDB debugger.
Check out my comment and program on
http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1630
Well, I disagree that you should close the bug. The point is: we agree
that it is a VERY BAD programming practice, etc, etc.
But if you implement this (as possibly MS-DOS does), then you get a
system which is more stable, although we are fixing a problem which is
not ours.
I don't think it's a big deal to do a
if (is386+) { XOR EAX, EAX; etc etc}
anyway, or am I missing something?
Aitor
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Hi! 9--2004 20:19 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: (Clear high parts of 32bit regs...) How this relates to DOS? EA MS DOS basically had no 386 stuff at all (except EMM386). In FreeDOS, EA however, people run 386 aware programs more often. Those leave non-zero EA values in 32 bit registers when they exit, and the next program which you EA start... EA Whatever. You are right. Very bad programming practice to expect the high EA parts of the 32 bit registers to have some value. Expecting _any_ undocumented value is very bad practice, and changing FD only because some super-demo doesn't run properly, I think, not very good. Unfortunately, in case of undocumented 16-bit registers, some other useful programs also may expected specific values. EA I close that bug report then. Fine. EA If it would be DOS4GW then we would be really motivated :-). ...to built DOS4GW into kernel? You joke. EA I meant if DOS4GW had problems with FreeDOS because FreeDOS does not EA clear high parts of 32 bit registers on exec then we should probably EA clear high parts of 32 bit registers on exec... But now that only an EA old GRDB is affected, I simply marked the bug as RESOLVED WONTFIX. Right. This is coding bug in consequent application, OS shouldn't try to fix all possible errors in any possible application. EA You just said that BIOS would handle it and that equipment list can handle EA up to four drives as well. So why would we need a driver sys for it? And I Because MS-DOS need it. From first versions there was reserved only two letters for floppy drivers, and we can/should not change this. Especially, programs with two controllers very rare... EA I see no convincing technical reason why FreeDOS should not auto-detect the EA more than 2 floppy drives exist ...and? What next? Assign C: and D: for those additional drives? All other (non-adjacent to A: and B:) drive letters will mislead users. EA working computer has one. Do we need to change the FreeDOS Manifesto in EA order to drop DRIVPARM / DRIVER.SYS plans? No. DRIVPARM not _add_ drive letters, it _changes_ properties of already registered. For example, on one broken computer with help of DRIVPARM I say to DOS that change line doesn't working (properly). My (old) computer have no APM support. EA FDAPM does not need APM. If you have it, FDAPM can use it. If not, no EA problem. All x86 CPUs have the HLT instruction... EA Things which you can do without APM with FDAPM: turn VGA on/off, spin IDE EA harddisks down (SPINDOWN command), save energy with help of HLT instruction, EA using APMDOS command, show statistics about that energy saving TSR mode, EA reboot through out 64,fe / through jmp :0 / through int 19. Ok. How I may/should test the FDAPM? Where it (URL)? EA About bug 1789, kernel confused by PKZIP-builtin format command Which URL? EA http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1789 I look at this. EA the ret / ret 8 issue in fl_lba_ReadWrite (when did that bug get INTRODUCED? When Bart changes fl_* function from ASMC to ASMPASCAL calling convention. EA Maybe I better downgrade to some older kernel / upgrade to a CVS kernel???). Better to fix the bug(s). :) --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
!
9--2004 16:17 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:
(Clear high parts of 32bit regs...)
How this relates to DOS?
MS DOS basically had no 386 stuff at all (except EMM386). In FreeDOS,
Lawrence comments that this only affected an old version of the GRDB debugger.
Well, I disagree that you should close the bug. The point is: we agree
that it is a VERY BAD programming practice, etc, etc.
But if you implement this (as possibly MS-DOS does), then you get a
MS-DOS is a 16-bit OS.
I don't think it's a big deal to do a
if (is386+) { XOR EAX, EAX; etc etc}
anyway, or am I missing something?
Ok, let suggest, some demo-maker makes demo, which will depends from
size of IO.SYS. How we should fix FD in this case?
A Yes, I agree with Aitor. We recognize it as a bug, if and only if, it
A breaks MS-DOS compatibility.
It not breaks MS-DOS compatability, there is only breakage with
alone configuration of alone program coder.
A That is implicit in FreeDOS manifesto, but
A if it only breaks an unimportant program, it can be set to low priority
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Kernel bug parade / moving on
Eric Auer escreveu: Hi Aitor, Alain, please ask Lawrence first if the MS DOS kernel clears the 32 bit registers. I bet that it does NOT. I hope he answers this ;-) This is not related to is the program which breaks unimportant. if it non-existant, then... Alain --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Arkady V.Belousov escribi:
!
9--2004 16:17 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:
(Clear high parts of 32bit regs...)
How this relates to DOS?
MS DOS basically had no 386 stuff at all (except EMM386). In FreeDOS,
Lawrence comments that this only affected an old version of the GRDB debugger.
Well, I disagree that you should close the bug. The point is: we agree
that it is a VERY BAD programming practice, etc, etc.
But if you implement this (as possibly MS-DOS does), then you get a
MS-DOS is a 16-bit OS.
io.sys and msdos.sys are 16-bit, emm386.exe is 32-bit.
I don't think it's a big deal to do a
if (is386+) { XOR EAX, EAX; etc etc}
anyway, or am I missing something?
Ok, let suggest, some demo-maker makes demo, which will depends from
size of IO.SYS. How we should fix FD in this case?
It will never work then, because KERNEL.SYS will never be as small/big
as IO.SYS+MSDOS.SYS
A Yes, I agree with Aitor. We recognize it as a bug, if and only if, it
A breaks MS-DOS compatibility.
It not breaks MS-DOS compatability, there is only breakage with
alone configuration of alone program coder.
For me the key testing is to check wether MS-DOS kernel does this. If it
does, then it is a clear compatibility breakage.
Until it is tested by someone, I'd say that the bug shouldn't be closed
or set as WONTFIX or such (no matter how much we wish it to be true).
Aitor
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Hi! 9--2004 23:26 [EMAIL PROTECTED] (Aitor Santamar?a Merino) wrote to [EMAIL PROTECTED]: MS-DOS is a 16-bit OS. ASM io.sys and msdos.sys are 16-bit, emm386.exe is 32-bit. But emm386 is not part of kernel. Ok, let suggest, some demo-maker makes demo, which will depends from size of IO.SYS. How we should fix FD in this case? ASM It will never work then, because KERNEL.SYS will never be as small/big ASM as IO.SYS+MSDOS.SYS Why not? Make stub with given size, which will call the real kernel file - and viola. But I don't think that this is right way for kernel. Especially because tomorrow another application will depend from IO.SYS size from other MS-DOS version (and/or another installed driver will change registers differently). It not breaks MS-DOS compatability, there is only breakage with alone configuration of alone program coder. ASM For me the key testing is to check wether MS-DOS kernel does this. If it ASM does, then it is a clear compatibility breakage. If in some configuration (in MS-DOS) you load some driver and you will not load this driver under FD and some program without this driver will behave differently, then this is _not_ and issue of FD. ASM Until it is tested by someone, I'd say that the bug shouldn't be closed ASM or set as WONTFIX or such (no matter how much we wish it to be true). Right now I run (16-bit) MS-DEBUG and inspect registers (with help of pushad instruction, as offered by Eric): some high parts are nonzero (for example, EBX and EDX). --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Hi! 9--2004 22:13 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA http://www.coli.uni-sb.de/~eric/stuff/soft/fdapm-16apr2004.zip I test it. APMOFF, APMBIOS, INFO, STATS and STANDBY doesn't work (no APM). About flushing cache in standby don't know. SUSPEND stops my hardisk. Wow, it was too noisy! :) Playing CD-ROM also stopped. POWEROFF stops the disk, but not turn off the VGA, whereas VGAOFF and VGAON both works (of course, VGAON I was should type blindly :). All *BOOT options are work, with HOTBOOT equal to COLDBOOT. Well, I think, there are not enough options like IDEOFF (and, probably, IDEON). :) On the other side, I hear, that spinning down/up disks too often is not very good for their mechanics. Environment: MS-DOS, QEMM. EA Just use the /? function to find out more. Of the *APM* options, EA only APMDOS (aka. ADV:...) will work and stay TSR. All other options Hm. FDAPM loads as TSR (and eats 800 bytes). What I should expect from this and how to measure effect? BTW, FDAPM doesn't diagnoses wrong options: for example, when I type advdos instead apmdos and try to find resident module, I not found it, whereas FDAPM don't say me that I was wrong. STATS after this says me about idleness percentage (98% in DOS, ~60% under Windows). Not very user-friendly number. Hm, reading docs: there sayed that this is time of using HLT versus total FDAPM loaded time. Why not say this sentence in STATS screen? Also, you may show total and idle times itself. Ops, found in doc mention of SPINDOWN, SPINUP, which not mention in help screen. Anyway, when I run SPINDOWN, FDAPM shows five dots after Spinning down message and freezes (without returning to command line). EA do not make FDAPM go TSR by the way. The /? screen does not mention EA the SPINDOWN command, but the docs do. Ops, I already found this. :) EA Have fun... Nice program. :) --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Hi! 7--2004 04:48 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA * 698 floppy change / floppy DMA boundary check should be moved from EA int 25/26 to the int 13 handler. Hm. Probably I not very understand this request, but FreeDOS does all DMA checks in dsk.c:LBA_Transfer(). EA Moving the check to int 13 means that DOS programs which use int 13 directly EA never have to worry about DMA boundaries. MS DOS provides this service. It EA also EA hooks int 13 to have more secure detection of disk changes (i.e. even if the Hm. I myself don't ready to introduce such (complex) feature. EA * 1176 second floppy controller not detected. FreeDOS detects second floppy drive presence through analyzing equipment list (INT 11) ... EA Yes, sure, but I wrote about second floppy CONTROLLER. This is the thing EA to which you connect the third and possibly fourth floppy drive and which EA - I believe - can only be found in 808x PCs, not in newer models. Not sure EA if the BIOS has or needs special support for that as well. As I understand, for BIOS this is easy: floppy drives numbered from 0 to 7F, hard disks numbered 80..FF. Thus, BIOS allows to have 128 floppy drives. :) Of course, eqipment list enumerates only up to four drives (two bits). Inefficient logic: with bit 0 eq.list there was possible to enumerate up to 7 drives. How DOS should deal with third and fourth drives - I don't know, but I suggest, this is possible only through driver.sys (there you point physical drive number 0..127, and it traps next logical drive letter). In any case, this is not issue for kernel itslef (unless you builtin driver.sys functionality, say, over drivparm= statement) EA * 1630 int 21.4bxx should clear the high parts of the general 32 bit ? _Why_ DOS should clear hight parts of 32-bit registers?! EA Because some programs would conceivably assume that the high parts are 0 EA instead of setting them to 0 manually. Check www.256b.com to see that DOS EA programs sometimes assume quite a lot of stuff about initial register EA values. FD _already_ imitates most MS-DOS (undocumented garbage) - see task.c:load_transfer(), where Lucho adds some initializations. I don't think that we should add there also dealing with 32-bit registers, especially I doubt that (16-bit) MS-DOS deals with high parts of 32-bit registers. To make UMBs, DOS uses XMS services. EA Good point. Then UMBs on pre-286 PCs would need really special drivers. Of course. EA Anyway, you can tell the user that UMBs are almost impossible if you detect EA an 808x at boot time then (i.e. if the user tries to use UMBs then the error EA message can be more helpful: If 286+, suggest loading an XMS plus if needed EA an extra UMB or if 386+ EMM386 driver. If 808x, suggest giving up X-)). Same Ie. you offer to integrate help, tutor and training subsystem into kernel? Currently DOS ignores DOS=UMB statement, if there are no UMBs available. I think, extra messages like NO UPPER MEMORY AVAILABLE FOR YOUR DOS=UMB STATEMENT makes only uncomfortable noise. I think, such messages is an issue for system information programs - for example, Manifest from QEMM package offers `Hints' menu, where it offer tips how to optimize the system (like Reduce the number of DOS FILES allocated). EA * 1789 the builtin disk format (!) function causes weird kernel error EA message LBA-Transfer error... EA Sorry, there is a word missing in the above!! EA The builtin disk format function OF PKZIP causes weird kernel error message EA ... Hm. May you give details? --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: LBACache test results
The Somertons schreef: Justin If I recall correctly, Interlnk never had FAT32 support, so I hope C: isn't FAT32. as alternative to FD(X)XMS, we now use HIMEM.EXE , included in the EMM386 package. ftp://ftp.devoresoftware.com/downloads/himem64.zip [22-04-2004] is probably most recent. Bernd --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: LBACache test results
I only used Interlink on FAT16 drives for the tests. True, InterLink does not support FAT32 because FAT32 didn't exist when InterLink was made. However, on normal MS-DOS, if you run InterLink/InterServer on a FAT32 drive, it won't crash or suffer data loss, it simply reports the drive as 268 MB (doesn't matter what size it really is), and the drive will be inaccessible on the other computer. If I recall correctly, Interlnk never had FAT32 support, so I hope C: isn't FAT32. as alternative to FD(X)XMS, we now use HIMEM.EXE , included in the EMM386 package. ftp://ftp.devoresoftware.com/downloads/himem64.zip [22-04-2004] is probably most recent. Bernd --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] bug: floppy.asm
Hello Arkady, I found another bug: - when fl_lba_ReadWrite() converted to ASMPASCAL (and `ret' replaced by `ret 8'), ret_AH remains as label for this tail (whereas other functions use plain `ret'). then remove the label, compile, and see what happens :(( tom --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] bug: floppy.asm
Hi! 7--2004 19:32 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: I found another bug: - when fl_lba_ReadWrite() converted to ASMPASCAL (and `ret' replaced by `ret 8'), ret_AH remains as label for this tail (whereas other functions use plain `ret'). te then remove the label, compile, and see what happens :(( Of course, it (NASM) should complain (because this is used label). Solution is easy: duplicate epilog code, but with plain `ret'. I already made this fix, now wait when Keneth will be ready to start update the CVS. --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Kernel bug parade / moving on
Eric Auer escribió: Hi Justin, thanks for your help offer! Win 3.11 can only run in 386 multitasked mode, 386 ENHANCED mode it would be interesting to get fresh test results (kernel 2035, new himem or maybe ms himem, better no emm386, maybe use DOS=LOW and a non-XMS-Swap FreeCOM for the test as well) for the 286 mode of Windows 3.0 / 3.1 (use WIN /S to start in this mode - you may want to use other enable compatibility stuff options of WIN as well, not sure). you mean running the STANDARD mode, that can also be run in a 386 In 286 mode, Windows can run on a 286 (you guessed that, right?). Aitor suggested that it only runs one DPMI task at a time then, swapping the other stuff to XMS. Well, what I suggest is that Windows (KRNL386.EXE) runs as a DPMI app, which is what it is actually, a DPMI app. Under a DPMI app you can run other DPMI apps, and have some multitasking using WSWAP, similar to the DSWAP of DOSSHELL. Aitor --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel bug parade / moving on
I think this kind of bug list would best appear on the 'FreeDOS @ SourceForge' page, since it directly relates to the kernel. Eric: would you like me to add you to that project on SF so you can create/maintain this page yourself? -jh Eric Auer wrote: Hi, while we have no real kernel maintainer right now (I assume Jeremy can at most find enough time to upload patches submitted by others, not for doing coding / testing himself), I think it would be good to review some old bugs before we move on to do new optimizations. Of course now that Arkady already has optimized things: If no new bugs get introduced those patches can of course be added. But I think we should focus on a bit of bug testing and fixing now for a while. I hope there are people on the list who can test some of the issues (i.e. have the affected type of software / hardware around!). Bugzilla URLs all look like http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id= where is the number of the bug in question (no leading zeroes). You can also use the http://www.europa.sp.nl/campagne2004/waakhond.shtml page to get a list of all bugs (just select a sort by and submit the form as-is) and http://www.freedos.org/bugs/bugzilla/ (just enter a bug number - you actually can NOT enter search terms in the latter form! Now for the bugs. If you are able to test a bug, please do so. [...] Maybe we could put a technote online with this list or something? Some of the abovementioned bugs are very exotic, so we may have to search the world for testers who can reproduce the described bug triggering conditions... and most normal people will not read the whole bugzilla system when they find the FreeDOS homepage and have a glance at the project status. -- _ This email message has been automatically encrypted using ROT-26. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: LBACache test results
Hi, please do turn off HTML in your mail program - use only plain text: Sorry, I just reinstalled Windows and forgot to set OE back to Plain Text, it's on Plain Text now. Why did you use STACKS=9,256 - how about STACKS=0,0 ??? Because STACKS=9,256 is a very common setting; I thought it was the best one. Anyway I should try that (STACKS=0,0) In what way did you copy the same file 10 times? From one directory to another on the same drive/partition I think for test b) you need a bigger LBAcache for that, something like THREE megabytes. Please try that (both LBAcache and the writeback feature of SMARTDRV store WRITTEN data in the cache. Therefore if you copy 1.2 MB disk - disk, BOTH the source file and the target file will be stored in the cache!). Good idea. Thanks for re-testing already ;-). You're welcome. I like to help DOS related projects whenever the opportunity is right. PS: If INTERLNK crashes FreeDOS, how about INTERSVR? And did it help to - load no HIMEM / EMM386 - use no XMS swapping FreeCOM - use no UMBs / do not load DOS to HMA - ...? I didn't bother with InterServer since it is useless without Interlink. I should test InterServer anyway, thanks for reminding me. I also tried diverse configs with same results. Anyway I should try more configs to see if IL is willing to work. You just wrote various contents for config sys - but to get started, an as fail-safe as possible config would be better. Sorry about that, I tried DEVICE=INTERLNK.EXE as the only line in CONFIG.SYS, then I added XMS drivers in subsequent tests. Still got Invalid Opcode (followed by a bunch of hexadecimal gibberish). In my PC 340, when I used FDXMS.SYS, the computer rebooted after loading InterLink. When I used Microsoft/IBM HIMEM.SYS, I got the Invalid Opcode, when I used no XMS driver on the PC 340, I got Invalid Opcode. IIRC, on my 386 both XMS drivers yielded Invalid Opcode. Anyway, I got a decent start on it, thanks for the tips, now we can go further with this on my Pentium Class PC 340 and my 386 SX. Heck, maybe we should later try File Maven, a freeware alternative to InterLink/InterServer, if IL/IS has no hope for FreeDOS. Justin --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Hi! 5--2004 11:22 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For [...] KJD If there are no objections, then about once a week I will go KJD through the kernel mailing list archives [I no longer assume I Not neccessary, I may repeat all my posts. Especially, they was not all. KJD Is this acceptable? or is there someone else already doing this? KJD wanting to do it? etc. Looks like no one other pretends to this role. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Arkady V.Belousov escreveu: Hi! Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For example, my current todo contains at least 6 bugfixes for dsk.c, and 2 which I don't know how to handle. Beside this, there optimized out some hundreths of bytes. Until someone else steps up and has the time, if wanted, I can do my best to apply patches for bugfixes to the kernel cvs sources. I should already have the necessary access to commit to cvs, but do not do so as I do not wish to step on anyone elses toes. If there are no objections, then about once a week I will go through the kernel mailing list archives [I no longer assume I get all my emails, as my mail box fills up daily with spam and false bounce messages] and apply patches or initiate further discussion. I will send a message to the list to indicate what patches are applied, so if I miss any or whatever, we can can discuss them further. This will pretty much be apply patches only, as I doubt I will have the time for indepth bug solving. As soon as Bart, Tom, or whomever deemed appropriate wants to continue doing so, I'll go back into my lurk mode. Is this acceptable? or is there someone else already doing this? wanting to do it? etc. Thanks, Jeremy Davis [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel bug parade / moving on
Hi Eric and the FreeDOS kernel people I would like to test some of them for you. Windows 3.11 Workgroups, I tried it, it kicks me back to DOS with Unsupported version of MS-DOS error (Used K2035 16-bit). Could you explain 1049 for me a little bit more? 1176, is that for two Floppy drives in the same machine or two separate ribbons? 1743, I have two old computers, the right cable, and two different versions of Interlink/Interserver 1768, Maybe that's why Solitaire Suite crashes with a Memory Allocation Error (this does not happen on MS/PC DOS). When you are on the front end of the menu and you choose a game, it crashes. However, if you run individual games from command prompt, they work fine. SS was written in QB 4.5. LBACache Slow Computer Test - I own an IBM PS/2 Model 56 SX which is an Intel 386 SX 20MHz with 12 MB RAM. Is that slow enough (also it uses a SCSI hard drive)? Justin - Original Message - From: Eric Auer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 05, 2004 8:17 PM Subject: [Freedos-kernel] Kernel bug parade / moving on Hi, while we have no real kernel maintainer right now (I assume Jeremy can at most find enough time to upload patches submitted by others, not for doing coding / testing himself), I think it would be good to review some old bugs before we move on to do new optimizations. Of course now that Arkady already has optimized things: If no new bugs get introduced those patches can of course be added. But I think we should focus on a bit of bug testing and fixing now for a while. I hope there are people on the list who can test some of the issues (i.e. have the affected type of software / hardware around!). Bugzilla URLs all look like http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id= where is the number of the bug in question (no leading zeroes). You can also use the http://www.europa.sp.nl/campagne2004/waakhond.shtml page to get a list of all bugs (just select a sort by and submit the form as-is) and http://www.freedos.org/bugs/bugzilla/ (just enter a bug number - you actually can NOT enter search terms in the latter form! Now for the bugs. If you are able to test a bug, please do so. * 423 Quicken 7 does not notice Linux write protection of files in DOSEMU. Instead, Quicken believes to write to the file in FreeDOS (while it fails to open the file at all in DR DOS, probably trying to open for R/W). * 698 floppy change / floppy DMA boundary check should be moved from int 25/26 to the int 13 handler. This is also needed for later when we want Win 3.1x /3 compatibility. Please comment on how hard it would be to move the boundary check function. * 735 if you remove a disk during access, FreeDOS has problems to give up in the middle of the access. No idea how other DOSes handle this. * 943 boot failure on dual Pentium III system with all-SCSI drives... * 994 some remote drive letter thing called RIFS network has problems with FindFirst/FindNext. We did have some related bugfix a while ago, but nobody had a suitable test system to check if that solved 994 as well. * 1049 Abort Ignore Retry Fail semantics might be incorrect... * 1176 second floppy controller not detected. Am I right in writing in the bug report that this can only affect 808x systems? How about required BIOS support, if any? A solution could be to interpret the installed hardware bitmask from the BIOS differently if CPU is 808x!? * 1630 int 21.4bxx should clear the high parts of the general 32 bit registers - of course this must check if CPU is 386 or better first. I think a CPU detection at boot time could also provide other advantages: If CPU is 808x, you can disable HMA detection and stuff (but I believe UMBs can be possible on 808x), and if CPU is 386, you can enable 32 bit processing in two or three most performance interesting inner loops like the memcpy function (where else?). And of course the test will allow optimized for ?86 kernels to show a message instead of crashing when you attempt to run them on x86 with x being a too small number... * 1651 FreeDOS failed to notice a disk change during access (kernel 2029) and then wrote buffered data from the first disk to the second disk, bad. * 1658 the Norton Ghost file browse dialog cannot see files on CD-ROM with kernel 2029/2033, but works with 2027 (not sure why this is a SYS bug). * 1688 initdisk complains about unknown partition types instead of ignoring them when you boot from a floppy. * 1743 INTERLNK / INTERSVR (the MS serial/parallel port network drive letter thing) crashes on FreeDOS. So if you have it and you have FreeDOS: Test it. * 1753 Netware VLM crashes on login. To test, you need a Netware server... The strange thing is that in 2026b, Netware NLM crashed, and since 2027, NLM works but VLM crashes! You need himem but do not need emm386. If you had needed emm386, I had suspected
Re: [Freedos-kernel] kernel administration
Could we ask Lucho to come back? He has helped a lot in the past. those that have hes address could write him... Alain Arkady V.Belousov escreveu: Hi! Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For example, my current todo contains at least 6 bugfixes for dsk.c, and 2 which I don't know how to handle. Beside this, there optimized out some hundreths of bytes. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Seems to me that the kernel is getting ever so close to perfection. - Original Message - From: Arkady V.Belousov [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 04, 2004 4:06 PM Subject: [Freedos-kernel] kernel administration Hi! Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For example, my current todo contains at least 6 bugfixes for dsk.c, and 2 which I don't know how to handle. Beside this, there optimized out some hundreths of bytes. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] (no subject)
Hi! 2--2004 07:47 Arkady V.Belousov wrote to [EMAIL PROTECTED]: AVB Subject: [Freedos-kernel] (no subject) This was should be patch: ioctl.c. AVB (replaces previous patch) AVB - 3 nested switch splitted into 2 switch (1st prepares parameters for AVB 2nd, which calls execrh()). AVB - device attribute word checked through table lookup. AVB - CharReqHdr.r_command computed through table lookup. AVB - removed all goto, except one. AVB Result: AVB DGROUP increased from 1646 to 167c (54 bytes), AVB TGROUP decreased from de6e to dd4e (288 bytes). AVB _DATA segment increased from 248 to 27e (54 bytes), AVB HMA_DATA segment decreased from a482 to a36e (276 bytes). AVB diff -ruNp old/kernel/ioctl.c new/kernel/ioctl.c --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [announce] kernel 2035 and bye
Hi, It's sad to hear that you say bye, but hopeful to read that you mention at least a break for two months, although I understand your reasons. Could I ask you something before you go? Could you please review bugzilla and try, as far as you understand/know about it, leave the kernel bugs in a state that represents current kernel 2035? (i.e. close the bugs that have been fixed, for example). If you haven't already done this, of course. Aitor Bart Oldeman escribió: Hi, I've uploaded kernel 2035 to http://sourceforge.net/project/showfiles.php?group_id=5109 important fixes: Fix problems with USBASPI.SYS, DI1000DD.SYS Fixed invalid opcode with debug foo.txt, same with netware redirected logins. Don't move the EBDA by default. Use switches=/e:-1 if you want the auto-sized movement (#1771) Made int21/ah=25,35 reentrant. Solves problem with Intel PRO/1000 driver. Fix dir corruption bug if you delete the first entry in the root directory on FAT32. Fix non-working F5/F8 for autoexec.bat (#1777) With this I'm leaving FreeDOS for the next couple of months at least. I may put up an update for MEM but that's it. There was a bit of noise on the mailing list but the main reason is that I'm generally happy about the kernel, all I wanted in the beginning is to get it to cooperate nicely with DOSEMU. That's done and more. Squeezing even more bytes out of the kernel and fixing even more bugs is certainly possible, but it's time to leave that to someone else as my (volunteer) job is finished. Thanks for your attention and help, Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-devel] Re: [Freedos-cvs] kernel/hdr device.h,1.21,1.22
Hi! 30--2004 09:24 Arkady V.Belousov wrote to [EMAIL PROTECTED]: No, all right: r_catfun is a xreg.x and r_cat is a xreg.h. Mistake is in my comment: I was should say difference is that r_cat comes _after_ r_fun to make consistent with CX. BO No, it can't be. See Table 02597 in RBIL at int2f/ax=0802, BO ---command codes 13h,19h--- BO which is what the patch implemented. AVB Ok. When I receive latest sources, I review them. ...but my change consistent with previous source. For example: was if ((rp-r_count 8) == 0x48), now if (rp-r_cat == 0x48). Ie. _was_ category value _after_ function value. PS: r_cat and r_fun at first look was associated for me with kitten and funny. :) --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.68,1.69 fatdir.c,1.46,1.47 fcbfns.c,1.42,1.43 ioctl.c,1.27,1.28
Hi! 24--2004 09:34 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: Ops, mistype. Should be: te I HATE 'oops, mistype' style bugs introduced for no purpose into a te working kernel. NiP (Nobody is Perfect). Bart also sometime introduces silly bugs in the kernel. Just slightly more arithmetics. te Probably easy to read for some russian programming god; I'm not a god and I'm not the most follower for replacement of code flow constructions by (low level) arithmetics. For example, I know the man, which will replace next code: r.AL = (r.CL 3) ? 28 : 29; by something like: /* r.CL % 4 == 0 ? 29 : 28 */ r.AL = (((r.CL 1u) | r.CL) 1u) ^ 29u; But I slightly conservative. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: portab.h, exeflat.c
Hi! 24--2004 21:34 Arkady V.Belousov wrote to [EMAIL PROTECTED]: AVB +++ new/hdr/portab.h 2004-05-24 21:31:58.0 + AVB #ifdef I86 /* commandline overflow - removing /DPROTO AVB TE */ AVB #define PROTO AVB #endif BTW, I think, _all_ _remained_ references to PROTO name may be removed: in dsk.c, turboc.cfg, and, of course, in portab.h. First, there are already a lot of (unconditional) prototypes, which anyway not enclosed by PROTO. Second, I doubt that now you may find (useful) C compiler, which not support prototypes. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: portab.h, exeflat.c
Hi! 24--2004 20:16 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: -#define LENGTH(x) (sizeof(x)/sizeof(x[0])) +#define LENGTH(x) (sizeof (x)/sizeof *(x)) te (sizeof(x)/sizeof(x[0])) has worked for me for ~20 years now. te could you please explain why this should be fixed (other then your fun te to change everything) Well, there are a lot of possibilities, which you can't predict. For example: #define f(v) (type)(v) Looks safe? But try it in: f(v)[0] and you under trouble, especially if both `type' is a pointer type and `v' is a pointer. In above case at first glance I don't see possibilities to break integrity ([] have top most priority over other operations), but this not mean, that such case can't be constructed by some smart man, which knows language even better. PS: For some peoples macros min()/max() also may work for ~20 years, but this doesn't mean that these macros are unbreakable, this just mean, that there wasn't used arguments with side effects. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: portab.h, exeflat.c
Hello Arkady, In above case at first glance I don't see possibilities to break integrity ([] have top most priority over other operations), but this not mean, that such case can't be constructed by some smart man, which knows language even better. another 10 points to get plonked. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hi! 24--2004 22:14 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: te the original code reads: te if (GetBiosTime() - startTime (unsigned)timeout * 18) tebreak; te and now I want to get an example when this breaks. For example, set timeout 30 seconds and run 10 seconds before midnight. Then above code willn't wait all 30 seconds, but not more than 10 seconds. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hello Tom, +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u) + return 0x; } + while (r.flags FLG_ZERO); This is not good way to calculate delays - around midnight (when system timer will be reset) above expression will be calculated wrongly (because GetBiosTime() will be lesser than startTime). bla. blubber. blabla. the original code reads: if (GetBiosTime() - startTime (unsigned)timeout * 18) break; and now I want to get an example when this breaks. Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55. Timer expires at 00:00:00 (0-1.5M = very large number) instead of 00:00:05. The (unsigned) cast for (GetBiosTime() - startTime) makes absolutely no difference in this respect. Signed numbers won't help either. Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: portab.h, exeflat.c
Hi! 24--2004 22:15 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: In above case at first glance I don't see possibilities to break integrity ([] have top most priority over other operations), but this not mean, that such case can't be constructed by some smart man, which knows language even better. te another 10 points to get plonked. Plonked? PS: Better to always be consistent and, if standard recommends use brackets around parameters, use brackets. This prevents a lot of (possible) headaches. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hello Bart, if (GetBiosTime() - startTime (unsigned)timeout * 18) break; Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55. Timer expires at 00:00:00 (0-1.5M = very large number) and that's exactly the wanted behaviour. instead of 00:00:05. but it times out, and doesn't wait indefinitively. and to wait precisely 10 seconds in the case that someone boots FreeDOS at midnight AND is sitting at the keyboard AND thinks it's a bug that the timer gotes off early is simply not worth the code to handle this case. +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u) and the original code uses long arithmetic on purpose. tom --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hi Tom, Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55. Timer expires at 00:00:00 (0-1.5M = very large number) and that's exactly the wanted behaviour. is it? At least the comment doesn't say so, maybe it was in your head though. instead of 00:00:05. and to wait precisely 10 seconds in the case that someone boots FreeDOS at midnight AND is sitting at the keyboard AND thinks it's a bug that the timer gotes off early is simply not worth the code to handle this case. well I do agree it's a highly unlikely situation. +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u) and the original code uses long arithmetic on purpose. The original code only pretends to use long arithmetic: if (GetBiosTime() - startTime = (unsigned)timeout * 18) break; The reason is that (unsigned)timeout * 18 is a 16 bit value. GetBiosTime() - startTime will under normal circumstances (outside midnight) *never* be = 0x1, since it increases step by step from 0 and bails out before it gets even close. Hence it is perfectly OK to cast to (unsigned). If you have a purpose to use long arithmetic then the original code needs to be: if (GetBiosTime() - startTime = (unsigned long)timeout * 18) break; Now what am I missing here? Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reference compiler (was Re: [Freedos-kernel] Re: patch: inthndlr.c)
On Mon, 10 May 2004, Bart Oldeman wrote: Hi Tom, You don't remember correctly. the kernel reference compiler has been for a long time TC 2.01 (which is free), and has been changed to OW because it generates better (smaller) code, and because it's free and open. Aitor remembers correctly -- he simply goes a few years further back than you and me. Before August '99 TC 2.01 couldn't be used. Watcom's been used as reference since Feb 2002. http://fd-doc.sourceforge.net/spec/spec.html Section Programming Tools To Be Used Our reference standard for a C compiler will be Borland C 3.1. Our reference standard for Assembly will be Microsoft MASM. Borland C 3.1 was chosen as the reference standard because this is the compiler used to build the FreeDOS kernel. Microsoft MASM was chosen as the reference standard because of the free availability of MASM-compatible assemblers. The existing code base was also a deciding factor in choosing a reference standard. How about to change the reference compiler not only for the kernel, but for all the project? There had been a movement from MASM to NASM already, so this can be reflected here as well. This is missing some documentation as well, right? It would be helpful to have some port MASM -- NASM document. I know Jim can phrase the change of the reference tools so that Turbo C becomes a backup-solution, not to be turned down immediately. Arkady, how is your progress toward OW going? Did have you assembled a Mini-DOS-OW development environment, for instance? I just unpacked any ZIP, except that ones specifically marked as Fortran. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: inthndlr.c
Hi, Steffen Kaiser escribi: Although, I would also keep the doing of the past to not press people to have to port project too heavily to OpenWatcom. However, it would be good to have a fd-doc for Newbies about OW in action. I had put together would was posted here into: http://freedos.sourceforge.net/freecom/ow.html I think you should update the last comment (by Bart), you can now use DPMI with EMM386, right? Aitor --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: Reference compiler (was Re: [Freedos-kernel] Re: patch: inthndlr.c)
Steffen Kaiser escribió: How about to change the reference compiler not only for the kernel, but for all the project? There had been a movement from MASM to NASM already, so this can be reflected here as well. This is missing some documentation as well, right? It would be helpful to have some port MASM -- NASM document. I know Jim can phrase the change of the reference tools so that Turbo C becomes a backup-solution, not to be turned down immediately. I vote for it. Perhaps it could be a question of mentioning the two, with preference for OW (but being clear that the other is ok too). Same for MASM/NASM Aitor --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: Reference compiler (was Re: [Freedos-kernel] Re: patch: inthndlr.c)
On Mon, 10 May 2004, Arkady V.Belousov wrote: It works (compiles programs). I even already prepared ATTRIB edition, which compilable by TC/BC/OW, and delay its release only because wait, if I found some new ways to reduce RTL (by replacing some RTL functions) - currently ATTRIB.EXE after BC uses 3914 bytes, after OW 4044 bytes. Oh yes, feel free to send me this to see where it can be reduced -- I remember you asked a while ago. The attrib 2.1 source I can see here uses fputs so that would be an obvious one to replace with one that just does a call to _dos_write if you don't need the buffering. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] bug: talloc.c
On Mon, 10 May 2004, Arkady V.Belousov wrote: __O\_/_\_/O__ d:\lang\tc\tcc -c -Id:\lang\tc\include -I..\hdr -DFORSYS -DWITHFAT32 -Ld:\lang\tc\lib -mt -a- -k- -f- -ff- -O -Z -d talloc.c Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International talloc.c: Error talloc.c 21: Type mismatch in redeclaration of '__brklvl' Warning talloc.c 66: Non-portable pointer assignment in function malloc Warning talloc.c 80: Non-portable pointer assignment in function malloc _ O/~\ /~\O Strange, I don't see this. Where is __brklvl defined for your Turbo C? As for your other patches, they take a lot of time to digest for the reasons I gave you already, so be patient. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Reference compiler / changing the spec
Hello Eric, BC xx wouldn't have worked after my HMA additions. I hope you make that clear somewhere. Otherwise, people try to use BC... I was talking about history; at these times it simply couldn't compile with any BC. It would be helpful to have some port MASM -- NASM document. Two solutions: Use Arrowsoft ASM (freeware). It supports not-too-complex MASM/TASM files. Good for the existing code base. what 'existing' source base ? there's no MASM sources around. and noone cares enough to port TASM-NASM, unless you DO IT YOURSELF. And I really hope that it will be possible to compile the kernel with Turbo C in the near future. this sentence disqualifies you as an even semi serous contributor to the kernel list. please go away. is it something like the bible, or should it be something reflecting (intended) reality ? I suggest that it describes reality, but that original intentions are not removed but just marked as obsoleted. I think, that a spec should describe the projects intention. and it's certainly not the kernels intention to be compilable with any compiler. the intention is to build a MSDOS compatible kernel; use the approriate tools (free if possible) Config sys compatibility: For ME, non-menued (DOS 5?) config sys is fine, and I am not worried by the fact that our menu language is different. Might be a point which is open for discussion. it's not open for discussion. it's open for PROGRAMMING. Are you sure that there can be up to 64 STACKS? I thought only 8..16? it makes only sense for the number of hardware interrupts (8..16) Okay for me to drop SETVER. because you don't understand it's purpose (your implementation implies that at least) Still GPL is preferred, of course :-). I'm pissed by GPL - for known reasons. tom --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Reference compiler / changing the spec
is it something like the bible, or should it be something reflecting (intended) reality ? I suggest that it describes reality, but that original intentions are not removed but just marked as obsoleted. I think, that a spec should describe the projects intention. and it's certainly not the kernels intention to be compilable with any compiler. the intention is to build a MSDOS compatible kernel; use the approriate tools (free if possible) Yes. See my other message in the original thread: The original intent was to have the Spec reflect what people actually _use_ so that when a new developer comes into the project, he/she will know what tools to use when contributing to FreeDOS (such as OW for C compiler, etc.) When the Spec was first written, no open tools (suitable for 16bit deployment) were available. However, pretty much everyone on the FreeDOS lists had (or was already using) TurboC or Borland C, so TC/BC were listed as the standard. Same thing for assembly, except that's changed now too. I'll try to get all of fd-doc updated very soon now. The Spec will be my first goal. -jh -- _ This email message has been automatically encrypted using ROT-26. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Reference compiler / changing the spec
XYZ=TRUE in config.sys? THIS WAS INTENDED NOT TO BE DOCUMENTED. THANKS FOR AMKIING IT PUBLIC. no kind regards tom --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Splitting patch
On Sun, 9 May 2004, Eric Auer wrote: why did you only mention in THIS mail what the MEANING of your patches is? You normally send a mail with subject like patch: filename.c and then there is ONLY the patch, zero explanation of any kind, nobody except you will know what you are trying to tell us and why your patch is supposed to improve things. So please 1. send some description along with the diff and 2. comment the changes in-line before you run diff and 3. tell us why the patch is good and whether you expect it to be good for all compilers or only for one certain compiler. Agreed except with 2.: I don't like commenting your change in-line. This produces very noisy code. Comments should tell why the code does something not what it does differently from what it does before. Otherwise you get code like: foo(); /* this call added by Eric Mar 2003 */ bar(); /* changed by Tom Apr 2002 */ baz(); /* bart changed this from hat() in June 2001 */ About Barts decision to take a break from FreeDOS kernel development: Could you please try to stabilize the current CVS version as 2034a release? I can try but the fixes will need to be isolated first from the patches that are floating around. Also I seem to have requests to: a) repair the EECHO command in config.sys so that it really works. b) disable the EBDA-move by default c) move the EBDA-move to after loading device drivers. Well implementing and testing all that will take quite a bit of time so I can't promise much right now. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CVS access (was re: fattab.c...)
On Sun, 9 May 2004, Bernd Blaauw wrote: Bart seems to be the only one with CVS access. No. Everyone has CVS read (anonymous) access. The tarballs are just there for those are cannot or can't be bothered to install a CVS client, and also sometimes the SF anon access can be a little flaky (it was a couple of months ago, it's better now). The people with CVS write access are: bartoldeman Project Admin jhall1 Project Admin jimtabor Project Admin perditionc Project Admin (Jeremy) reifsnyderb Project Admin roncemer Project Admin skaus Project Admin (Steffen) tomehlert Project Admin all these people can add new people too. From looking at the CVS logs it seems that each project only has one person committing to a project but that's not how the permissions are -- I am able to change the FreeCOM CVS files if I like to (in fact I did so once but that was a very small obvious change, I didn't want to step on Steffen toes too much here). BTW if CVS sounds to complicated and you're on Windows you can check out http://www.tortoisecvs.org/ is Lucho still (silently?) active? yes. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: break.c
Hi! 9--2004 16:58 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO Please, if you send a patch, state the purpose. BO Why do you think this is necessary? break.c: removed extraneous variable initialization. dsk.c: optimization. initdisk.c: - fix: is_suspect(). - fix: nHardDisk now limited by MAX_HARD_DRIVE, not MAX_HARD_DRIVE-1. - hardly optimized LBA_Get_Drive_Parameters() call (for example, memset() moved inside). - ddt initialization moved into separate function make_ddt(), removed extraneous pddt pointer. - other small optimizations. BO If it saves on code size, how many bytes does it save for OpenWatcom? break.c: 4 bytes. total over all three files: TGROUP reduced from 0E222h to 0E1D1h; HMA_TEXT reduced from 0A66Ah yo 0A65Eh, INIT_TEXT reduced from 3BB2h to 3B71h. (Note: fix for is_suspect() increases code). --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: config.c
On Sun, 9 May 2004, Arkady V.Belousov wrote: - small optimization: `init' and `inittail' now assigned to .cfgInit and .cfgInitTail statically. - removed COMMAND statement. TGROUP reduced from 0e1d1h to 0e1c6h; INIT_TEXT reduced from 3b71h to 3b66h; ICONST reduced from 9b8h to 996h; I_BSS reduced from 0e7ch to 0df6h; IDATA increased from 57ah to 5fah. I don't think it's good to reduce BSS at the cost of DATA. Some people like uncompressed kernels to be as small as possible too and the BSS isn't showing up in kernel.sys :) (except for MSVC) Even for compressed kernels having all zeros at the end helps: less entropy. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel problems and problem loading high DISPLAY
Hi, If I understood Eric's point, it might be UPX fault, as it would fail whenever it tries to enlarge the UMB as required by the uncompressed program and silently fails. So I may have to provide uncompressed 64KB DISPLAY.COM in the next release (last before DISPLAY.SYS). On the other hand, in the same situation MS-DOS seems to deal with this situation correctly (that is, if it can load high then loads low), and FD-DISPLAY will not have problems there, so there's something about FreeDOS kernel too. Bernd seems to have found other problems regarding UMB management and kernel. Aitor [EMAIL PROTECTED] escribió: On Sun, 2 May 2004, Bernd Blaauw wrote: I have a problem with loading high the DISPLAY driver. Aitor mentioned that it requires maybe up to 64KB initial memory, and then shrinks itself. My problem is that instead of loading low when LH fails, the entire command fails. that implies: Load DISPLAY.COM high, or don't load it at all! (instead of: Load DISPLAY.COM high, and if that fails load it low) There is one problem with LH *.COM files: .COM files often believe they get plenty of memory when loading, vs. EXE files where you (the implementor) say beforehand how much memory is required to run the program. So, if the .COM image is smaller than the actual memory required, is is loaded, but then fails (using abort() or something) during startup phase. (Borland dies with exit code #3 then, BTW). You are right that FreeCOM's LH does not re-exec a program low, if it fails to load it high, but it will display an error message, if the actual exec() _syscall_ fails - in contrast when the program got loaded, but died itself. Maybe you should file a bugreport, if MS COMMAND behaves differently - regardless if the current problem is not related to it. Probably MS kernel and FD kernel provide different unused UMBs. To verify this problem, you could create a little .COM program, to just display the block size the program got loaded into; then extend the .COM file to the same file size than DISPLAY.COM, this is necessary to enforce the kernels to load the test program into the same UMB as DISPLAY.COM. (Maybe, you have to trick, when you use C, so the C startup library does not try to resize the block to 64KB and fails thereby probably. -- switching to assemlby seems to be better here at all.) Bye, --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel problems and problem loading high DISPLAY
Hello Aitor, If I understood Eric's point, it might be UPX fault, as it would fail whenever it tries to enlarge the UMB as required by the uncompressed program and silently fails. So I may have to provide uncompressed 64KB DISPLAY.COM in the next release (last before DISPLAY.SYS). make an .EXE file of it, and forget this CPM compatibility clutch of .COM files. tom --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel problems and problem loading high DISPLAY
DOS=UMB is causing a lot of problems. Unfortunately it's not possible to use UMBPCI (want to exclude EMM386 as a cause..) on Bochs. Bernd set path=a:\freedos LASTDRIVE=Z BUFFERS=20 FILES=40 DOS=HIGH DOS?=UMB ;DUMMY?=YES set dircmd=/ogn DEVICE=A:\DRIVER\HIMEM.EXE /VERBOSE DEVICE=A:\DRIVER\EMM386.EXE NOEMS I=C800-CFFF X=D000-EFFF /VERBOSE SHELL=A:\command.com A:\ /P:A:\autoexec.bat --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel problems and problem loading high DISPLAY
hi Bart, Bochs has no PCI, so UMBPCI does not work. any comments on the original message I posted? do you want me to publish a Bochs zipfile including my FreeDOS configuration, so anyone can reproduce my encountered problems? unlike VMware, Bochs is completely platform-independent and thus won't be influenced by host processor type and speed for example. my problems happen when DOS?=UMB is answered with Y (YES). I don't think it's EMM386 making problems, but the FreeDOS kernel. Bernd --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] macroses
Hi!
30--2004 23:32 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
#define lonibble(v) (0x0f (v))
#define hinibble(v) (0xf0 (v))
BO hinibble is ambiguous. Suppose I use
BO hinibble(0x1234)
BO with your macro I get 3 and not 1.
This depends how you _wish_ understand this. I understand this as
hinibble gets hinible in byte, hibyte gets hibyte in word, etc. So, no
ambiguites, also as for AL/AH/AX/EAX.
BO same problem here. hibyte(0x12345678) = 0x56
Yes. For higher bytes apply hiword: lobyte(hiword(v)) and
hibyte(hiword(v)). Very convenient and readable.
BTW, you may _name_ this as nibble0(), nibble1(), byte0(),
byte1(), etc, but this is question of taste.
These macroses allow to make more readable
BO I don't agree.
You may dislike hibyte name. Ok, hibyte is no such important as
lobyte, inline it: lobyte(v)8. But again, _expression_ is (usually) less
readable, than good name for it. Also, for some compilers you may have more
efficient ways to get hibyte(), than , like for MK_FP in BC used _seg
modifier.
BTW, about _seg. _You_ yourself offer use _seg for BC. I implement this
(const psp _seg *p instead psp FAR *p or seg_t psp_seg) and found that
this is identical to seg_t psp_seg:
__O\_/_\_/O__
@@ -1945,28 +1925,24 @@ VOID ASMCFUNC int2F_12_handler(struct in
case 0x20: /* get job file table entry */
- {
-psp FAR *p = MK_FP(cu_psp, 0);
-unsigned char FAR *idx;
-
+{
+const psp _seg *p = FP_SEG_PTR (const psp, cu_psp);
[...]
-idx = p-ps_filetab[r.BX];
+r.ES = FP_SEG (p-ps_filetab);
+r.DI = FP_OFF (p-ps_filetab + r.BX);
r.FLAGS = ~FLG_CARRY;
-r.ES = FP_SEG(idx);
-r.DI = FP_OFF(idx);
- }
- break;
+break;
+}
_
O/~\ /~\O
__O\_/_\_/O__
+#if __TURBOC__ 0x202
+# define FP_PTR(type,seg,ofs) ((type FAR*) MK_FP (seg, ofs))
+# define FP_SEG_PTR(type,seg) ((type _seg*) (seg))
+#else
+# define _seg FAR
+# define FP_PTR(type,seg,ofs) ((type FAR*) MK_FP (seg, ofs))
+# define FP_SEG_PTR(type,seg) ((type FAR*) MK_FP (seg, 0))
+#endif
_
O/~\ /~\O
But you ignore this (your offer). Why? Also, you again don't answer why you
don't fix (yet) is_suspect (although you already agreed that this was right
way)?
more portable
BO Not at all. v 0xff is the most portable construct.
Ok, rephrase: at least, same portable. Also, for some compilers you
may tune code (in one place) and remain portable.
and, in some cases, more effective code.
BO When?
I already quote you listing, how BC generates worser code for ch -=
'a'-'A' without casting ((UBYTE)('a'-'A')). Also, don't remember if I
quote you listing, but (my) lobyte generates for BC better code (because no
extra instructions like and dl,255).
BO Do you mean that Turbo C puts in stupid code such as
BO and ax, 65535?
BO well that's the compiler's fault, not ours.
Of course. But why not use more readable code, if it _also_ generates
_not worser_ code (and better for some compilers)? Also, a = 0x0f b is
shorter, than a = b 0x0f.
put_unsigned((unsigned)(clussec 0xu), 16, 4);
You may wrote:
put_unsigned(loword (clussec), 16, 4);
BO I think it should just be:
BO put_unsigned(clussec 0xu, 16, 4);
BO as Turbo C is too stupid to realize that these two values do not lose any
BO significant digits I'm forced to disable that warning using -w-sig...
It not stupid, it just not presents too many extensions over
standard. Same I (and you) may say about OW. I already report this for OW
team:
__O\_/_\_/O__
Language and libraries:
- (with -wx option) WPP diagnoses (W716: integral value may be truncated)
bytevar 0x18 expression, which passed to byte parameter.
_
O/~\ /~\O
__O\_/_\_/O__
#ifndef I86 /* the latter assumes byte ordering */
BO This code was already reorganized completely.
Yes, I found this after I wrote my letter. But this is only example,
how to code may be enhanced with help of mentioned macros.
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149alloc_id66op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
Re: [Freedos-kernel] Re: Network Card problems
[EMAIL PROTECTED] writes: the driver for the Intel Etherpress/pro 100 (100 Mb) works for me, both under MS-DOS and freedos... Perhaps this driver works with your card, too, perhaps with only 100 MB? No. The PRO/1000 is a completely different card which uses a completely different driver. I have lots of PRO/100 hardware, and that driver (e100b.dos) works fine. For PRO/1000 hardware, you must use the e1000.dos driver, and that is the one which has problems. - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
wcc (wpp neither) can't compile multiple files at the sametime. You can only try to decrease the load time of wcc.exe Maybe compressing it or binding with a dos extender helps. Maybe not. I use it in RAM-DISK (with xmsdsk), allong with all .H files and some more ;-) Alain --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] cvs refresh
Arkady V.Belousov wrote: Hi! 24--2004 17:05 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO Date: Sat, 24 Apr 2004 17:05:18 +0100 (BST) When latest patches will be reflected in CVS snapshot on site (kernel.tgz?)? I wish to check how they are applied in complete. BO every day at 10am GMT How GMT relates to UTC (which TZ)? I mean, how GMT relates to my MSK TZ (which is currently +4 to UTC)? Arkady: Your time zone is GMT+0400. So at 10am GMT, it is 2pm in your TZ. -jh -- _ This email message has been automatically encrypted using ROT-26. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
On Sat, 24 Apr 2004, Arkady V.Belousov wrote: 24-áÐÒ-2004 15:53 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: +++ fattab.c 24 Apr 2004 15:53:21 - 1.22 -idx = (unsigned) unsigned)Cluster1 1) + (unsigned)Cluster1) 1) - % dpbp-dpb_secsize; - +idx = (((unsigned)Cluster1 1) + (unsigned)Cluster1) % dpbp-dpb_secsize; Bug: in my patch was Cluster1 1 - difference is that code above computes 3*Cluster1 instead 3*Cluster1/2. Sure I already found that and corrected. But please note that replacing fbp by bp-buffer[foo] really doesn't produce better code for Watcom. There is a good reason why I didn't apply these blockio.c patches either. Bart --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
On Sat, 24 Apr 2004, Arkady V.Belousov wrote:
24-áÐÒ-2004 16:37 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO fbp by bp-buffer[foo] really doesn't produce better code for Watcom.
BO There is a good reason why I didn't apply these blockio.c patches either.
:) For OW I don't review listings yet, only for BC. I plan do this for
OW today-tomorrow, though, this is much longer (up to 10 minutes with BC for
recompilation, up to 20 with OW). Probably, I should force my efforts in
optimization of makefile (collect names of changed files in one file, then
pass this list at once for compilation).
if you want to check things quickly, simply do
wcc -i..\hdr -os -r -s -j -d1 -DWITHFAT32 foo.c
(perhaps via some batch file)
wcc (wpp neither) can't compile multiple files at the sametime. You can
only try to decrease the load time of wcc.exe Maybe compressing it or
binding with a dos extender helps. Maybe not.
wpp is not good -- the kernel is written in C, not C++, and some small
differences like sizeof('a') (1 in C++, sizeof(int) in C) maybe
responsible for what you see. It's also bigger so just slows things down.
Bart
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg297
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] cvs refresh
On Sat, 24 Apr 2004, Arkady V.Belousov wrote: When latest patches will be reflected in CVS snapshot on site (kernel.tgz?)? I wish to check how they are applied in complete. every day at 10am GMT Bart --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] cvs refresh
Hi! 24--2004 17:05 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO Date: Sat, 24 Apr 2004 17:05:18 +0100 (BST) When latest patches will be reflected in CVS snapshot on site (kernel.tgz?)? I wish to check how they are applied in complete. BO every day at 10am GMT How GMT relates to UTC (which TZ)? I mean, how GMT relates to my MSK TZ (which is currently +4 to UTC)? --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
Hi!
24--2004 17:01 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
recompilation, up to 20 with OW). Probably, I should force my efforts in
optimization of makefile (collect names of changed files in one file, then
pass this list at once for compilation).
BO if you want to check things quickly, simply do
BO wcc -i..\hdr -os -r -s -j -d1 -DWITHFAT32 foo.c
BO (perhaps via some batch file)
I do so for BC (with -S option). :) Ask again: how you get listings for
inthndlr.c? When I dsiasm it, then second half of listing was not contain
sources (desyncronization?).
BO wcc (wpp neither) can't compile multiple files at the sametime. You can
__O\_/_\_/O__
fc=file_name
(C++ only) specify file of command lines to be batch processed (see
fc=file_name)
_
O/~\ /~\O
BO only try to decrease the load time of wcc.exe Maybe compressing it or
BO binding with a dos extender helps. Maybe not.
Hm. May be try the 32lite exepacker? Though, don't sure if this help
(much) - WCC already runs from Stacker volume.
BO wpp is not good -- the kernel is written in C, not C++, and some small
BO differences like sizeof('a') (1 in C++, sizeof(int) in C) maybe
BO responsible for what you see.
? I not use WPP with kernel (yet). Also, should be unimportant by which
compiler compiled compiler, if its sources are valid.
BO It's also bigger so just slows things down.
Yes, WPP is 50% longer. :(
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg297
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EBDA movement FUD
Hello Michael, Hi, I would like to spread some fear, uncertainity and distrust about EBDA movement! MD Can you give the exact syntax on using that in CONFIG.SYS. MD Is it a bare SWITCHES=/E line on its own? Yes, it's a bare switches=/E I had to discover this this morning, too, as running device=S-ice.exe /EMM 4000 also nukes the PC. It seems, Softice is moving the EBDA by itself and in addition to the kernel, to the PC ends up with 641KB, which would only be nice if it worked. tom --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] initdisk.c: bug?
Hi! 22--2004 19:36 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: Should be easy to test: just disable floppy drives in BIOS setup. Try to test what give FreeDOS in this case later (today), when finish to study 2034. BB I can easily test it by doing a harddisk install, BB then removing floppy and cdrom and booting from harddisk. Not need to remove, just say Not Installed for both floppy drives in BIOS setup (usually first submenu - Standard CMOS Setup). BB I'll let you know. Thank you. PS: Just tested under MS-DOS - unfortunately, MS-DOS continues to assign drive letter A to (unavailable) floppy drive. (For z: command command.com says `Invalid drive specification', for a: command it not says this, only Abort, Retry, Ignore, Fail). :( --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] initdisk.c: bug?
Hi! 22--2004 20:32 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: BB does FreeDOS project have any mount diskette as floppy software? BB for cdrom we have the SHSU-package (shsucdx used mostly) Don't know if this is already reproduced, but in MS-DOS you may do this with help of driver.sys - it may be used, for example, to make drive letter with 720k properties on 1.44M drive. Of course, this not affects A (and B in case of both floppy drives present). To change parameters of A and B, DRIVPARM statement should be used. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel blockio.c,1.30,1.31 dosfns.c,1.61,1.62 int2f.asm,1.27,1.28 proto.h,1.61,1.62 task.c,1.41,1.42
On Thu, 22 Apr 2004, Arkady V.Belousov wrote: Current CVS against latest official release. freedos-cvs@ is a good place to publish alone patches with comments, but they are often (as now) crosses and have other troubles with applying (I ask about this questions, but have no answers). if you apply them in the right sequence then there should be no problems. If there are then you are quite capable to sort them out yourself -- just a question of your time versus my time and i prefer to be lazy :) 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: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel blockio.c,1.30,1.31 dosfns.c,1.61,1.62 int2f.asm,1.27,1.28 proto.h,1.61,1.62 task.c,1.41,1.42
Bernd Blaauw escreveu: Bart distributes 8086 kernels, not 80386 optimized kernels. Lucho does that. Not any more :( Lucho unsubscribed form both FreeDOS list. He was very annoyied about some things here. I would be nice if he received some encouragement messages from some of us ;-) Alain --- 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] Microsoft beginning to assert FAT Patent
Hi! 20--2004 11:23 [EMAIL PROTECTED] (Steve Gibson) wrote to [EMAIL PROTECTED]: SG The Public Patent Foundation has submitted a request to the United States SG Patent and Trademark Office (USPTO) to reexamine patent 5,579,517, awarded Is my post in freedos-devel with the same news not arrive there some days ago? --- 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_id70alloc_id638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Q: release files
Hi! 20--2004 15:46 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: at the 80686 and newer. No idea about transportation costs though.). A The bigger problem could be Russian Custums... A Arkady, what are the rules there? Never deal with it (directly), though, I successfully receive (Master C Programmer) certificate from (ex)Tecmetrics by mail and Intel architecture books from Intel by FedEx. --- 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_id70alloc_id638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-devel] Recent Bugzilla entries
Bernd Blaauw escribi:
Arkady,
is the auto-loadhigh part of Cutemouse difficult to integrate into
other programs?
I'm thinking about FreeCOM and KEYB. not DISPLAY, as that will become
a driver file anyway.
Unless I am wrong, no big deal here, would be a question of creating a
UMB MCB, and copy the resident code/data there.
The fact that it works depends greatly in the segment registers being
used correctly. I have cleaned this up in this first rewrite version,
but there's still something that I'd need before doing this.
First, the resident code is fully in assembler, EXCEPT for the return
instructions. The resident procedures are of the form:
===
procedure XXX; assembler;
asm
...
end;
===
whenever I call them from other places, or store their addresses (in
Pascal pointers are always far), I have to declare them far.
However, I have manually tried to place RET instructions and making
calls using only offsets just to see how it feels, and I have noticed
that it crashes.
So in order to get more control, I'd like to rewrite the whole of the
resident part as a chunk in NASM and try to link. But this will not come
soon in time.
BTW, as I don't want to waste any single byte and mess with linker/code
placement (I still ignore if {$L directive will link object code IN THE
SAME PLACE where it appears), perhaps turning that all into assembler
and creating other MCBs to place the resident stuff, will happen at the
same time. No sooner than KEYB2 pre2.
Aitor
---
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] TDSK volume locking failure
On Fri, 16 Apr 2004, Steve Gibson wrote: Just a note that the 2032 kernel fails volume locking on the tdsk.exe turbodisk device. mov bl, CurrentDosDevice; 1-based current device xor bh, bh ; lock level 0 mov cx, 084Ah ; category / lock logical mov ax, DOS_IOCTL SHL 8 + BLOCK_DEVICE_IO int 21 I get ax=0, no carry with kernel 2034rc. Doesn't seem like a problem to me. 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] TDSK volume locking failure
Hi Bart, Just a note that the 2032 kernel fails volume locking on the tdsk.exe turbodisk device. mov bl, CurrentDosDevice; 1-based current device xor bh, bh ; lock level 0 mov cx, 084Ah ; category / lock logical mov ax, DOS_IOCTL SHL 8 + BLOCK_DEVICE_IO int 21 I get ax=0, no carry with kernel 2034rc. Doesn't seem like a problem to me. Thanks Bart. I'll give it a try under the 2034rc kernel. --- 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] FORCELBA Kernel option
On Sat, 17 Apr 2004, Steve Gibson wrote: Could someone briefly explain the function of the kernel's FORCELBA option? The command shown by sys.com is Always use LBA if possible. So I suppose I'd like to understand why or when the kernel would not use LBA when it's available? If a partition isn't marked as LBA (with the partition id) then the kernel will uses CHS, unless it's beyond cylinder 1024. This is because some TSRs like to hook int13 and expect DOS to use the old int13 CHS style calls. If you don't like the somewhat inefficient LBA-CHS (by the kernel) and then CHS-LBA translation (by the BIOS) you can set ForceLBA. 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] kernel 2034rc for testing
On Fri, 16 Apr 2004, tom ehlert wrote: one thing I don't understand: MEM /F will show a 1K dataarea, between 2 FILES drivers, at ~2a6:0 this existed also in ke2033, and possibly before. as it *seems* to be unused, what is it? That would be the relocated EBDA. I should improve MEM to detect that one properly. BTW: I fullheartily disagree with your efforts to move share_check() into assembly, and I will never like #pragma aux, even if that saves a few byte. IMO this is dos-C, and should be coded in C (which is possible mostly) you'd have to be consistent. Most of the remote functions use assembly. So why have just one using intr()? Either use intr() for all of them or use external asm files for all of them. Since the resident code had only 4 or so intr() users it was easier to go for the external assembler. I left all the intr()s in the init code as is though -- since it's the predominant technique there. As to #pragma aux, this helps the Watcom optimizer quite a bit (about 350 bytes for the asmsupt.asm interfaces) -- without it even a memcpy in C would make a smaller kernel (but in the past you argued to do memcpy in assembly). Ironically as soon as you throw a normal __cdecl or pascal assembly function into the equation (whether intr() itself or anything else) the whole optimizer chain collapses. 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] kernel 2034rc for testing
Hi! 16--2004 20:30 [EMAIL PROTECTED] (tom ehlert) wrote to Bart Oldeman [EMAIL PROTECTED]: te into assembly, and I will never like #pragma aux, even if that saves a te few byte. Let me disagree with you. This is most valid and effective way to control compiler - in given case describe interface to (external) function. IMHO, this is much more flexible and better than modifiers (like ASMPASCAL) and cost only one additional line per each function in header file. te IMO this is dos-C, and should be coded in C (which is possible mostly) :) Some things (especially low level and which are complete in sense of functionality) may (and should) be implemented in asm. Especially when we talk about real OS, which may used as base for complex systems. --- 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_id70alloc_id638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2034rc for testing
So, by all means, if you want to test it, download it. If not, wait until the final release and then the next cycle of improvements can be made. I think the largest test population in the wild would be if Erwin Veermans included the testing kernel on his Nwdsk (Netware bootdisk). I successfully performed full test-runs of my FreeDOS bloated NwDsk NetWare boot disk (including the always picky NIOS.EXE) using the combination of kernel 2034rc, himem/emm386 from emm386rc, freecom 0.82pl3, udma 7.0, lbacache 14apr04, cdrcache 07apr04, shsucdx 2.1a, cutemouse 1.9 (all installed/loaded). Optionally I added/tested fdapm 27nov03 and mkeyb 0.39. Michael has provided me with some special himem testversions to tackle problems with DELL PowerEdges with big ram (2GB). Himem-rc is jamming on those. We are currently busy to pinpoint the chipset/bios or the huge size of ram as the culprit using some extra himem-switches. When Michael releases his final himem/emm386 and Tom makes that official (and compresses it as hard as he can !) I will submit a new NwDsk containing all above updates (including kernel) at the Novell site while hoping that it behaves just as smooth for my users as it does on my own test-machines ;-) Or I will get more NwDsk-email than spam for once ... As with Bernd: we can test as good as we can but only when it gets out on all exotic hardware/software of our end-users we know where we stand. For my NwDsk I expect little impact from 2034 but I will be closely whatching the acceptance of switching from UMBPCI to EMM386 (though it looks very promising!). 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] 2034rc feedback (and EMM386)
EMM386: FDISK /REBOOT causes Invalid Opcode, FDAPM WARMBOOT does the same Need to know the Invalid Opcode data to do anything about it, if can be. --- 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] 2034rc feedback (and EMM386)
Bernd Blaauw schreef: EMM386: FDISK /REBOOT causes Invalid Opcode, FDAPM WARMBOOT does the same FDAPM COLDBOOT does reset the computer FDAPM HOTBOOT works like good old QEMM: reboot to bootsequence immediately. (not that it has that great effect, but OK..) anything that can be done about it? don't know if the mentioned applications need to change, or EMM386, to accept warmboots. I'll check against MS EMM386. Bernd just checked against MS emm386.exe : this is an FreeDOS EMM386 flaw I'm not using EMM386 on bootdisk, but a fix in EMM386 would be nice (but not essential) to allow warmboot 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] kernel 2034rc for testing
Hi! 14--2004 17:16 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO http://freedos.sourceforge.net/kernel/kernel.sys (45k) BO The daily tarball is at the usual place (same directory, kernel.tgz, 334k) BO pat34rc.zip in the same directory has a source diff (79k). What is pat34rc? Diff between 2033 and 2034rc? Same directory - freedos.sf.net/kernel/? --- 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_id70alloc_id638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2034rc for testing
Arkady V.Belousov schreef: Fine. For the future: show URL for complete diff patch on the main page, previous time I don't found it (if it was present). Also, when planned 2034 release? May be I wait this release and download it completely (instead patch), if it will be soon? the idea is to test *before* spreading to the general public. I include this 2034 kernel in the next FreeDOS distribution, next Sunday. there have been a few times where a kernel was released, and a few days later a new kernel followed it because a larger public found a few bugs. So, by all means, if you want to test it, download it. If not, wait until the final release and then the next cycle of improvements can be made. I think the largest test population in the wild would be if Erwin Veermans included the testing kernel on his Nwdsk (Netware bootdisk). do we even have testing procedures? or would testing specific things first require a kernel changelog (history.txt)? 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
