Hi all,
Sorry for the delay. I just caught up on my reading of this list
yesterday.
IIRC, this thread started as a poll of what enhancements are
needed/desired for FreeDOS. There are 3 such things on my list.
1) Speed up disk writes
2) Let CTMOUSE load itself in either PS/2 or Microsoft mode even
when no mouse is detected.
3) Fix the mailing list digests so that the messages aren't weeks or
months old by the time the digest is assembled and sent.
I will describe each of these requests in more detail in the
following paragraphs. I'll take the last one first.
3)
The digest processing apparently waits until it has accumulated
~10 messages before it sends out a digest. I subscribe to 3 of the
FreeDOS mailing lists (User, Devel, Kernel) and AFAICT all three of
them do this.
The problem is, on lists with infrequent posts, it takes a long
time to accumulate ~10 messages. So, by the time that a digest is
finally sent out, the older messages in that digest may be weeks or
months old. In many cases, the info in those messages is out of
date by the time a digest subscriber (like me) sees it.
E.g. I received a digest from the FreeDOS-kernel mailing list on
September 17th. The first message in that digest was dated July
28th. If the poster of that msg had wanted a response from other
list subscribers, he would have been denied any chance of a response
from digest subscribers because of the way digest processing is
done.
Of the three mailing lists that I mentioned, the kernel list
suffers the most from this effect. That's because the kernel list
usually receives the fewest posts. But even digests from the devel
and user lists are sometimes delayed this way.
May I suggest that each list's digest processor be changed so
that it sends out at least one digest on any day when someone posts
to that list?
2)
Currently CTMOUSE will only load in Mouse Systems mode if it
does not detect a mouse. I would like CTMOUSE to offer the option
to load itself in either PS/2 mouse or Microsoft mouse mode when it
fails to detect a mouse. Is that feasible?
Why do I want that feature? Because I would like to be able to
use AccessDOS's (ADOS12.ZIP) MouseKeys implementation. And that pgm
only works if it finds mouse services available that support either
PS/2 or Microsoft mode.
Why don't I just attach a mouse so that CTMOUSE will load in
PS/2 or Microsoft mode? Because, on some systems, I can't.
On some systems, there are no available (physical) serial or
PS/2 ports. On other systems a mouse won't work for some unknown
reason. And on still other systems, the motherboard seems to be
unable to support some combinations of hardware simultaneously.
E.g. I've seen systems where the mouse stops working when the
soundcard is activated. And, on some such systems, the mouse starts
working again if you deactivate the soundcard (e.g. by unloading its
driver). On other systems, you have to reboot before the mouse will
work again.
On many of these systems, ADOS12 could provide an elegant work-
around - but only if a mouse driver is loaded first. But CTMOUSE
(and every other mouse driver that I've tried) will not load unless
it detects a mouse. Is this a "chicken and egg" problem?
1)
Tom Ehlert wrote:
>>>> Slow disk access, FreeDOS is the slowest among EDR-DOS and PTS-DOS ...
>>>WHAT 'slow disk access' (other then Lucho reporting this) ?
>
>> His test result have problem?
>I don't even know what tests he did.
>reporting problems SHOULD include something like
>
> XCOPY \dir1\*.* \dir2
>or XCOPY \dir1\*.* \dir2 /s
>or COPY \dir1\*.* \dir2
>or using VC version X.Y to copy \dir1 to dir2
>or etc. (here I think the 'etc.' is appropriate)
>
>with a directory nested 5 levels deep, with 352 files, average size
>~10 KB
>
>took the following times .... makes sense.
>
>makes sense. What Lucho comes close to marketing (read 'void of
>information').
>
>> Or you found out he did a wrong test?
>there is no 'wrong test'. there are irrelevant tests (like XCOPY
>only for files of zero byte, or only of 1 GB files), but given that no
>further information is available of what he tested, I can't judge.
>
>>>FWIW FreeDOS has read access to files close enough to theoretical
>>>throughput.
>
>> Only read?
>*I* care for read speed. so *I* optimized read speed (I thinks I did a
>reasonable job in that; before it was cruel).
>
>If anybody cares about write speed: this is an open source project.
>Take your time, fire up your editor. Call back when you're done.
I posted several times about this (i.e. write speed and disk
caching) to the FreeDOS-User list in late August 2006. Were those
posts insufficiently detailed? IIRC, I never saw anyone post saying
that they had done the same (or similar) tests. So I don't know if
others got the same results (as I did) or different results.
The results that I posted were pretty damning of FreeDOS's
performance. IIRC, in his response, Eric suggested that if
FreeDOS's buffering of disk writes were a little more aggressive,
then it might improve FreeDOS's performance. Has that been done and
I missed it?
As I'm sure everyone here is aware, FreeDOS does *not* exist in
a vacuum. There are lots of more or less equivalent OSs available
at practically no cost. E.g. I would guess that there are still
(collectively) tens of millions of copies of MSDOS, DRDOS, Novell-
DOS, PCDOS, etc. in peoples' closets, garages, and attics.
So if FreeDOS fails to provide performance that is (at least)
comparable to those other DOSs, then how many people will continue
to use FreeDOS? IOW how many users are *not* going to switch to one
of those other DOSs? Very few, I would think.
I switched. I.e. after those tests, I stopped using FreeDOS. I
still use DOS almost every day so the performance penalty of using
FreeDOS (instead of one of its competitors) seemed unacceptable to
me.
And Udo Kuhnt's fine work has extended the reach of DOS to some
more modern hardware (e.g. hard drive's larger than 8GB). That too
is competition for FreeDOS.
I'd be happy to test FreeDOS again and find that its performance
is now competitive. But up till now, I've seen no indication that
FreeDOS's performance has changed. If I missed such an announce-
ment, then I apologize.
So that's my answer to the poll. Only 1) is really a FreeDOS
problem.
And yes, I am aware that CTMOUSE has its own project and mailing
list. OTOH, I just accessed a CTMOUSE webpage today and downloaded
CTM20A4.ZIP. AFAICS, all the files in it are dated 2003.
So if anyone knows of a mouse driver (either CTMOUSE or another)
that meets my requirements, then please let me know via the list.
And if you don't get a response right away, then please be patient.
I may not have received the digest containing your post yet. :-)
Thanks.
-Eddie
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
