[Freedos-kernel] Re: Kernel bug parade / moving on
Hi, I think "idleness percentage" is easier to understand for users than
> time of using HLT versus total FDAPM loaded time
in general :-). Displaying TOTAL time is a bit complicated in NASM but would
be a nice extra ("uptime" display).
Only with the resident module you have an idleness percentage - the module
invokes HLT (and if possible the related APM func) whenever some wait style
function is called (e.g. wait for key). It counts during how many clock ticks
the "invoke HLT" happens. The HLT is supposed to save energy. Works for me
for AMD K6-2 and Cyrix/STS/IBM 6x86 M1, but I do not know about pre-486 / ...
whether it makes any difference. I am told that QEMM does not allow the DOS
vm86 task to HLT, so FDAPM has no effect if QEMM loaded (only affects some
QEMM versions on some CPUs it seems!?).
If even HOTBOOT worked for you then probably the hot / int 19 boot
(just reload OS, do not redo BIOS init) simply crashed for you, or QEMM
translated it into a coldboot...
Strange that spinning down disks sometimes works and sometimes hangs? You
said your BIOS has no APM, so it must have been FDAPM itself which did the
spin down!? The spin down stuff writes to the IDE controller directly and
is very simple, so probably no surprise if it is not too reliable. Funny
that it spins down CD-ROM as well :-). By the way, harddisks spin up by
themselves on demand, so SPINUP command is not really needed.
> Nice program. :)
Thanks :-).
Hmmm... why are we discussing this on freedos-kernel? Maybe because of
QEMM or because I wondered on how old hardware FDAPM can run (in theory:
on all hardware, but some options break, e.g. VGAOFF if you have no VGA
and battery information if you have no APM etc. - not to mention the
attempt to SPINDOWN without IDE...)???
Ah. Now I remember. The "FDAPM saves no energy because HLT has no effect
in combination with certain hardware and QEMM versions...". For my PCs I
can usually hear the power supply fan going to lower speed (it adjusts
speed depending on temperature) after a short while if FDAPM works and
saves energy. No big change but you can hear it.
Do not attempt to measure power consumption directly unless you really
have proper tools and knowledge for that. You could break your hardware
or yourself otherwise, which is definitely bad. Take no risks.
Eric
---
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! 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
[Freedos-kernel] patch: init-mod.h proto.h
Hi!
init-mod.h
- cleaned prototype for function from intr.asm.
- init_fatal() described (for Watcom) as non-returned functions.
proto.h
- fatal() and panic() described (for Watcom) as non-returned functions;
this improves code generation.
- cleaned prototypes for functions from intr.asm.
- removed prototypes for nonexisting functions.
- added brackets around parameters of macro.
About improved code generation: with `#pragma aborts' HMA_TEXT sement
reduced by another 5 bytes.
BTW, init_fatal() may be removed, because it not used.
--- Begin Message ---
diff -ruNp old/kernel/init-mod.h new/kernel/init-mod.h
--- old/kernel/init-mod.h 2004-05-29 02:51:30.0 +
+++ new/kernel/init-mod.h 2004-06-10 00:32:18.0 +
@@ -164,7 +164,7 @@ int ASMPASCAL close(int fd);
int ASMPASCAL dup2(int oldfd, int newfd);
seg ASMPASCAL allocmem(UWORD size);
void ASMPASCAL init_PSPSet(seg psp_seg);
-int ASMPASCAL init_DosExec(int mode, exec_blk * ep, char * lp);
+int ASMPASCAL init_DosExec(int mode, exec_blk * ep, const char * lp);
int ASMPASCAL init_setdrive(int drive);
int ASMPASCAL init_switchar(int chr);
void ASMPASCAL keycheck(void);
@@ -215,6 +215,9 @@ VOID ASMCFUNC FreeDOSmain(void);
BOOL init_device(struct dhdr FAR * dhp, char * cmdLine,
COUNT mode, char FAR **top);
VOID init_fatal(BYTE * err_msg);
+#ifdef __WATCOMC__
+#pragma aux init_fatal aborts
+#endif
/* prf.c */
int VA_CDECL init_printf(const char * fmt, ...);
@@ -312,4 +315,3 @@ ULONG ASMCFUNC FAR MULULUL(ULONG mul1, U
ULONG ASMCFUNC FAR DIVULUS(ULONG mul1, UWORD mul2); /* DIVide ULong by UShort */
ULONG ASMCFUNC FAR DIVMODULUS(ULONG mul1, UWORD mul2, UWORD * rem); /* DIVide
ULong by UShort */
#endif
-
diff -ruNp old/kernel/proto.h new/kernel/proto.h
--- old/kernel/proto.h 2004-05-28 12:09:02.0 +
+++ new/kernel/proto.h 2004-06-10 00:03:10.0 +
@@ -135,6 +135,10 @@ int ParseDosName(const char *, char *, B
VOID dump(void);
VOID panic(BYTE * s);
VOID fatal(BYTE * err_msg);
+#ifdef __WATCOMC__
+#pragma aux panic aborts
+#pragma aux fatal aborts
+#endif
/* fatdir.c */
VOID dir_init_fnode(f_node_ptr fnp, CLUSTER dirstart);
@@ -225,8 +229,8 @@ void FcbCloseAll(void);
UBYTE FcbFindFirstNext(xfcb FAR * lpXfcb, BOOL First);
/* intr.asm */
-COUNT ASMPASCAL res_DosExec(COUNT mode, exec_blk * ep, BYTE * lp);
-UCOUNT ASMPASCAL res_read(int fd, void *buf, UCOUNT count);
+int ASMPASCAL res_DosExec(int mode, exec_blk * ep, const char * lp);
+unsigned ASMPASCAL res_read(int fd, void *buf, unsigned count);
#ifdef __WATCOMC__
#pragma aux (pascal) res_DosExec modify exact [ax bx dx es]
#pragma aux (pascal) res_read modify exact [ax bx cx dx]
@@ -236,9 +240,6 @@ UCOUNT ASMPASCAL res_read(int fd, void *
COUNT DosDevIOctl(lregs * r);
/* memmgr.c */
-seg far2para(VOID FAR * p);
-seg long2para(ULONG size);
-void FAR *add_far(void FAR * fp, unsigned off);
VOID FAR *adjust_far(const void FAR * fp);
COUNT DosMemAlloc(UWORD size, COUNT mode, seg * para, UWORD * asize);
COUNT DosMemLargest(UWORD * size);
@@ -403,5 +404,4 @@ VOID ASMCFUNC exec_user(iregs FAR * irp,
ASSERT_CONST( (BYTE FAR *)x->fcb_ext - (BYTE FAR *)x->fcbname == 8)
*/
-#define ASSERT_CONST(x) { typedef struct { char _xx[x ? 1 : -1]; } xx ; }
-
+#define ASSERT_CONST(x) { typedef struct { char _[(x) ? 1 : -1]; } _; }
--- End Message ---
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Hi! 9-Июн-2004 22:13 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: >> ...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> No. Users with three floppy drives are users of computers where other DOSes EA> do indeed give C:/D: to floppy. AFAIK, other DOSes (by itself) don't give C: and D: letters to floppy drives. EA> But if we allocate drive letters after last EA> harddisk drive letter they will not be too surprised either. He _will_ be surprised, because other DOSes, which was used before, do not show extra drives (without instructing them about this). EA> In both cases EA> they will be more happy than if they cannot use the third drive at all. :) I myself never hear about computers with more than 2 drives, and I doubt that will hear about such computers (after introducing hard drives). EA> But then again, this only affects a very special class of 808x based PCs. >> 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). EA> You actually know such a piece of hardware? Right now I have _no_ computers/drives with broken change line. But who knows? >> Ok. How I may/should test the FDAPM? Where it (URL)? EA> http://www.coli.uni-sb.de/~eric/stuff/soft/fdapm-16apr2004.zip I try test it. >> EA> the ret / ret 8 issue in fl_lba_ReadWrite (when did that bug get INTRO... >> When Bart changes fl_* function from ASMC to ASMPASCAL calling >> convention. EA> Okay, but was that before he released 2035 or after? I don't remember precisely, but floppy.asm from kernel.tgz marked at 9 april of 2004. --- 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 20:19 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: >> 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 Ok, I see. May you extract for me precise URL of attachment (with diskette image)? I may try to test this image and test, how my patches affect this. EA> possibly fixed by you: EA> http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg00956.html I can't read this: :) :( __O\_/_\_/O__ Error: could not read mail message[Errno 2] No such file or directory: '/data1/archive/[EMAIL PROTECTED]/msg00956.html' _ O/~\ /~\O But if there is my patch for floppy.asm, then this is not the last patch, which affects formatting: I not (yet) publish changes in dsk.c, especially bugfixes for Genblkdev()/case 0x42 (format/verify track). Or, I may prepare test kernel for Matija, which will shown all values, used for computing LBA_address in Genblockio() for LBA_transfer() in case of mode==LBA_FORMAT. Righ now will write she (he?). --- 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
Салям!
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: Kernel bug parade / moving on
Hi, In response to Eric, Bugzilla is being used to track wishes as well as bugs (see the KEYB entry), as you can mark it as "feature". It is unknown to me if MS-DOS will do that. MS-DOS 1.0 will not do that, but one should just try an MS-DOS version after 1988. Arkady V.Belousov escribiÃ: 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. Have you ever read "Windows internals", which is about that user interface called "Windows 3.1". There are several functions in the main windows API (system/user/gdi) that patch already existing bugs or problems in other Windows applications, making it a very robust and thus worldwide known application. 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
[Freedos-kernel] Re: Kernel bug parade / moving on
Hi Arkady! > ...and? What next? Assign C: and D: for those additional drives? All > other (non-adjacent to A: and B:) drive letters will mislead users. No. Users with three floppy drives are users of computers where other DOSes do indeed give C:/D: to floppy. But if we allocate drive letters after last harddisk drive letter they will not be too surprised either. In both cases they will be more happy than if they cannot use the third drive at all. But then again, this only affects a very special class of 808x based PCs. > 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). You actually know such a piece of hardware? 360k drive while BIOS limited to 160k drive or what kind of strange beast needed that? See my above comment. > Ok. How I may/should test the FDAPM? Where it (URL)? http://www.coli.uni-sb.de/~eric/stuff/soft/fdapm-16apr2004.zip Just use the /? function to find out more. Of the *APM* options, only APMDOS (aka. ADV:...) will work and stay TSR. All other options do not make FDAPM go TSR by the way. The /? screen does not mention the SPINDOWN command, but the docs do. Have fun... HOTBOOT will most likely not work - just running int 19h to reboot only works if ALL drivers behave nicely and hook int 19h as a trigger to unload themselves, quite unrealistic. > EA> the ret / ret 8 issue in fl_lba_ReadWrite (when did that bug get INTRO... > When Bart changes fl_* function from ASMC to ASMPASCAL calling > convention. Okay, but was that before he released 2035 or after? What is the newest released kernel which is free of that bug? As you know compiling the kernel is more work than downloading it... What will trigger the bug, all LBA sector accesses? That would be a big problem then, should everybody compile the update themselves? Eric --- 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
[Freedos-kernel] Re: Re: Kernel bug parade / moving on
Hi Aitor, Alain, please ask Lawrence first if the MS DOS kernel clears the 32 bit registers. I bet that it does NOT. This is not related to "is the program which breaks unimportant". Arkady (hey, 3rd person with A..-name) told that this is a feature wish and not a bug report and I think he is exactly right with that. See bugzilla entry 1630, as usual... Eric --- 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
Aitor Santamaría Merino escreveu:
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
Yes, I agree with Aitor. We recognize it as a bug, if and only if, it
breaks MS-DOS compatibility. That is implicit in FreeDOS manifesto, but
if it only breaks an unimportant program, it can be set to low priority
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
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
[Freedos-kernel] Re: Kernel bug parade / moving on
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 > EA> If it would be DOS4GW then we would be really motivated :-). > ...to built DOS4GW into kernel? You joke. I meant "if DOS4GW had problems with FreeDOS because FreeDOS does not clear high parts of 32 bit registers on exec then we should probably clear high parts of 32 bit registers on exec"... But now that only an old GRDB is affected, I simply marked the bug as RESOLVED WONTFIX. > 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... I see no convincing technical reason why FreeDOS should not auto-detect the "more than 2 floppy drives exist" case instead of forcing the user to use clumsy driver.sys manually instead... On the other hand I see no reason why we should support a third floppy drive AT ALL. Almost no still existing and working computer has one. Do we need to change the FreeDOS Manifesto in order to drop DRIVPARM / DRIVER.SYS plans? Are there other devices for which DRIVPARM and DRIVER.SYS would be actually useful? Apart from pre-286 floppy / tape drives with broken BIOS support or similar stuff? > EA> do indeed suggest to make driver sys a kernel builtin if we need it... > This is not bug report, but wish. Yes, but we have no "Wishzilla" available. Only Bugzilla. If you want a better separation of bugs and wishes, we could enable the Sourceforge wish / helpdesk / buglist system again partially (i.e. activate only the wish database part of it. For helpdesk, people should go to FAQ and for bugs they should use Bugzilla). <-- COMMENTS, Jim? > My (old) computer have no APM support. FDAPM does not need APM. If you have it, FDAPM can use it. If not, no problem. All x86 CPUs have the HLT instruction... Things which you can do without APM with FDAPM: turn VGA on/off, spin IDE harddisks down (SPINDOWN command), save energy with help of HLT instruction, using APMDOS command, show statistics about that energy saving TSR mode, reboot through "out 64,fe" / through "jmp :0" / through "int 19". > EA> About bug 1789, kernel confused by PKZIP-builtin format command > Which URL? http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1789 possibly fixed by you: http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg00956.html the ret / ret 8 issue in fl_lba_ReadWrite (when did that bug get INTRODUCED? Maybe I better downgrade to some older kernel / upgrade to a CVS kernel???). (Poor Matija / Tom / Bart spam-bot-wise, but you needed the URL of bug 1789...) Eric --- 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
[Freedos-kernel] EBDA oddity / bug 1630
Hi, forwarding a comment by Lawrence, maybe interesting??? > Well, it happened in an older version of the GRDB > debugger. It has since been fixed. > > By the way, I don't have time to investigate this now, > but while I have your attention, I noticed that when > the BIOS allocates an XBDA at segment 9F80, FreeDOS > somehow ends up stuffing bad values into 40:E and > 40:13. It says that I have 643K of base memory, or > something rediculous, when I had only 638K left after > the BIOS took its chunk. Can you reproduce this? > It's easy to test. http://www.freedos.org/bugs/bugzilla/show_bug.cgi? id=1630 (please remove the linebreak to make the URL work) Eric --- 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
[Freedos-kernel] Final LBACACHE tests for now
Hi, Some more LBACACHE vs. SMARTDRV tests, I think these are the last ones for now. Tests for 386 SX/20, 31 MB FAT16 partition on SCSI hard drive CONFIG.SYS and AUTOEXEC.BAT remain the same except for the changes in caching method. No disk cache, 3:39 LBACACHE 2 MB, 2:54 SMARTDRV 2 MB, 2:34 SMARTDRV WC 2 MB, 1:15 LBACACHE 8 MB, 2:36 SMARTDRV 8 MB, 2:28 SMARTDRV WC 8 MB, 0:50 *** Info: LBACACHE 2 MB *** XMS handle has size (in kB) 2048 read hits: 00016871 read misses: 5971 write hits: 8396 write misses: 00011763 *** kilo-reads: 0022 --> percentage of hits: 0073 *** kilo-writes: 0020 --> percentage of hits: 0041 *** Info: SMARTDRV 2 MB *** Room for256 elements of 8,192 bytes each There have been 4,684 cache hits and 3,364 cache misses Cache size: 2,097,152 bytes drive read cache write cache buffering C: yes no no *** Info: SMARTDRV WC 2 MB *** Room for256 elements of 8,192 bytes each There have been 6,958 cache hits and 1,097 cache misses Cache size: 2,097,152 bytes drive read cache write cache buffering C: yes yes no *** Info: LBACACHE 8 MB *** 0x083A XMS handle has size (in kB) 8192 read hits: 00020675 read misses: 1967 write hits: 9444 write misses: 00010697 *** kilo-reads: 0022 --> percentage of hits: 0091 *** kilo-writes: 0020 --> percentage of hits: 0046 *** Info: SMARTDRV 8 MB *** Room for 1,024 elements of 8,192 bytes each There have been 4,682 cache hits and 3,339 cache misses Cache size: 8,388,608 bytes drive read cache write cache buffering C: yes no no *** Info: SMARTDRV WC 8 MB *** Room for 1,024 elements of 8,192 bytes each There have been 7,152 cache hits and812 cache misses Cache size: 8,388,608 bytes drive read cache write cache buffering C: yes yes no Tests for AMD K5 PR166, 256 MB FAT16 partition on IDE/EIDE hard drive CONFIG.SYS and AUTOEXEC.BAT remain the same except for the changes in caching method. No disk cache, 3:04 LBACACHE 4 MB, 2:40 SMARTDRV 4 MB, 0:42 SMARTDRV WC 4 MB, 0:35 LBACACHE 16 MB, 0:33 SMARTDRV 16 MB, 0:31 SMARTDRV WC 16 MB, 0:19 *** Info: LBACACHE 4 MB *** XMS handle has size (in kB) 4096 read hits: 00013968 read misses: 00042937 write hits: 3513 write misses: 00017897 *** kilo-reads: 0056 --> percentage of hits: 0024 *** kilo-writes: 0021 --> percentage of hits: 0016 *** Info: SMARTDRV 4 MB *** Room for512 elements of 8,192 bytes each There have been 8,543 cache hits and 10,315 cache misses Cache size: 4,194,304 bytes drive read cache write cache buffering C: yes no no *** Info: SMARTDRV WC 4 MB *** Room for512 elements of 8,192 bytes each There have been 15,021 cache hits and 3,873 cache misses Cache size: 4,194,304 bytes drive read cache write cache buffering C: yes yes no *** Info: LBACACHE 16 MB *** XMS handle has size (in kB) 00016384 read hits: 00043294 read misses: 00013613 write hits: 3556 write misses: 00017867 *** kilo-reads: 0056 --> percentage of hits: 0076 *** kilo-writes: 0021 --> percentage of hits: 0016 *** Info: SMARTDRV 16 MB *** Room for 2,048 elements of 8,192 bytes each There have been 10,211 cache hits and 8,573 cache misses Cache size: 16,777,216 bytes drive read cache write cache buffering C: yes no no *** Info: SMARTDRV WC 16 MB *** Room for 2,048 elements of 8,192 bytes each There have been 16,820 cache hits and 1,999 cache misses Cache size: 16,777,216 bytes drive read cache write cache buffering C: yes yes no I hope that these tests are useful to you. Justin --- 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
