Hi all,
my excuses for the length of this mail. I hope at least
Norbert and Blair will read all of it :-). The other
readers of the "EMM386 2.11" thread might want to join ;-)
For all the rest, the summary is: There is less poison in
the community than you think. HIMEM and EMM386 are better
than you think but improving them is a good thing. There
is a FreeCOM update available (newer than our ISO). The
list is quiet because Blair etc are processing 1.0 devel
things behind the scenes, but not "behind the scenes to
keep the community from enjoying the development". QHIMEM
has some "undocumented" extra features. DOOM works with
HIMEM, too. The "don't complain" sentence in the EMM386
docs is years old and from Tom, not from Michael. Sorry
for the miscommunication about the FreeCOM / diskimage
issue, Norbert. Explicit and detailled bug reports are
better than blaming people for bugs in general.
Please stop reading here if you only want to get an
overview. Well, do not forget to browse the text below
a bit anyway, to find the new FreeCOM download URL ;-).
> When reading the messages in developer mailing list, I'm wondering about
> where FreeDOS is moving. The developers are only blaming each other
> whole time. There's no normal discussion possible...
This is not true. You just read the mailing list at the one moment
when a flamewar about qhimem was going on.
> Why always discuss things off-list? Has the rest of the dos
> community no right to see what's going on in the development of the
> software they are using?
Honestly, I think the rest of the dos community does not say
anything at all, not even off-list. For example nobody writes
mail about my cache, neither on-list nor off-list, probably
because the cache has been working well enough recently :-).
So it is not the case that we use the list only for flamewars
and discuss all improvements off-list :-). You should also
visit the IRC if you are interested in the latest distro news
and gossip ;-).
> Even if Johnson told wrong facts in the field of programming, I must say
> that Michael Devore is the wrong man to judge this. It's a fact that his
> himem and emm386 clones are absolutely useless in a productive
> environment. There are too many bugs concerning different types of
> hardware and freedos very often crashes when using emm386. Using Jack R.
> Ellis qhimem and Uwe Sieber's umbpci is the only way to use Freedos with
> UMBs on nearly all kinds of harware by always using the same settings.
Very harsh words about FreeDOS HIMEM / EMM386. I think I deleted
MS HIMEM and MS EMM386 a year ago because the FreeDOS versions
were actually BETTER than the MS DOS 6.xx ones for me! They have
smaller memory footprint and work better with modern hardware...
On some hardware, UMBPCI has better performance and/or stability
than EMM386. But for example on my test PC, UMBs created by UMBPCI
are "slow memory", and loading CPU-intensive stuff like a cache to
that area makes the whole thing slow. UMBPCI also depends on having
exact knowledge about your particular mainboard chipset, while
EMM386 should work on all 386 and newer systems. Problems with
EMM386 are usually caused by incompatible BIOSes. You should test
if MS DOS EMM386 works with those BIOSes. If yes, please report.
If no, you cannot blame EMM386 - you are then simply stuck in a
situation where no protected mode based UMB providers work, and
where you have to revert to the real mode driver UMBPCI (which
cannot provide EMS, but most DOS programs do not need EMS...).
Later I installed the MS versions again for testing purposes with
Windows, but again found that Win3.1 works better with FD HIMEM :).
Notice that 386 enh mode of Win3.1 and WfW3.11 only works with
MS EMM386, but that all Win 3.x versions come with MS EMM386 on
the Win 3.x install diskettes anyway. The background is that the
heavy tweaks of 386 mode to make DOS "true multitasking" include
replacing the whole emm386 "on the fly" with a built-in driver
of the Windows kernel, which requires a complex interface called
GEMMIS. Nothing else apart from Windows uses GEMMIS, and because
of this, FreeDOS EMM386 does not include GEMMIS.
> [qhimem] is without any doubt the better and more reliable product
> for everydays use even if there are some features missing.
Did you try the FreeDOS memory managers in their newest versions?
Yes there were problems with EMM386 about VDS / SCSI / SATA in the
past, but at least HIMEM has been working fine for me for a long time.
The only advantage of QHIMEM is that it uses even less DOS memory.
As Jack does not reveal his sources, it is hard to tell which
other advantages ought to exist. I hear that he has "allow an IRQ
window after every move of a few (2? 4? 8?) kilobytes of XMS", to
improve realtime handling, but I doubt that this is actually
relevant unless you have a gbit ethernet card on a 486...?
> The worst thing is that Michael doesn't care about bug reports from the
> dos users that have problems running things like doom. But what does he
> say in his emm386 help file: "IF IT WORKS FOR YOU - FINE. IF IT DOESN'T
> - STOP USING, BUT DON'T COMPLAIN."
This is actually what Tom wrote in the help file, not what Michael
wrote. Tom decided at some point that EMM386 would be good enough
and will not be improved further. Michael usually tries to improve
EMM386 on request, if there is reasonable demand. But: DOOM does
work with the current himem/emm386. You only need a bit more RAM than
you would need with optimized versions of those drivers. So it is
probably okay that Michael is reluctant to put the update on high
priority.
> You're all talking about the upcoming 1.0 release. And I made my
> contribution to get rid of bugs. But no one cares. Since I discovered
> the bug introduced in command.com 0.84pre2 that redirection of ouput to
> a file isn't possible anymore I hear nothing...
Sorry to hear about that. Blair should have announced that
he recently fixed a serious bug in LFN handling and improved
stability a lot by removing the _REGISTER and __emit__ style
inline interrupt calls. The updated FreeCOM command.com is not
included in the current 1.0-Testing ISO / cdrom yet but it is
available as a separate download:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/0.84pre/
testing/command.com
> I sent different floppy
> images to Blair and Eric to reproduce the bug but nothing happens.
> Statement from Blair: "I can't reproduce the bug by using qemu".
As said, sorry that you did not get informed about the most recent
update, but please test it.
> Statement from Eric: "I won't open any images at the moment".
I was in another state, sleeping at a friend's place. I hope you
can understand that I did not install a DOS debugging environment
on his computer. Just booting your image would not have been
enough to analyze your FreeCOM bug.
> Did you ever try your own software without using an emulated environment
> like qemu which is still in beta state and additionally not able to
> reflect different hardware?
Yes, I have FreeDOS 1.0-Testing installed on my actual DOS partition
on my actual harddisk right now :-). And I must say that this makes
me one of very few people who sent Blair feedback about whether his
1.0-Testing disk works on any computer outside his house :-(. I did
find some bugs which I reported on the mailing list and found some
more which I reported directly via IRC. As far as I remember, they
were: The default config sys needs tuning, XDMA and QDMA make Windows
3.1 hang (IRQ or DMA troubles, Windows freezes in the welcome sound),
the CPX files are in the wrong directory, MORESYS is missing, FDAPM
should be in autoexec, DISPLAY and EMM386 and EDIT are not the most
recent version, a few binaries are not UPXed, FreeCOM has bugs. The
latter are fixed in the ibiblio update. There are more bugs in the
distro, but as said, I did report those on the mailing list already.
> think freedos development has come to an end. The euphoric mood of the
> last weeks about the upcoming 1.0 release is getting less and less as
> you can see by reading the postings on the list.
I disagree. We have a quarrel about HIMEM / EMM386. And Blair is
working on the next ISO, which is simply not really a topic to
discuss on the mailing list. I mean, it makes little sense to say
"today I got an update of package XYZ and copied it to my devel
PC, so it will be included when the next ISO is released" :-).
> If the remaining developers still want to give release 1.0 a chance they
> should discuss things in a more better way...
I think it helped to have moved past the Q-driver discussion once
again. It is usually good to have competition. But there also has
to be cooperation. So for example it would be okay if Jack said
"look, I insert IRQ windows in QHIMEM, now my gigabit ethernet
works better". But it is not okay to say "HIMEM violates some IRQ
related rules, as described in old MS documents, therefore you
are stupid. And I will not tell you how to fix this bug nor will
I provide test cases or examples of affected software/hardware..."
Unfortunately the latter is more or less what certain people said.
> And if you are all angry now, you can kick my ass off the list.
No. It is okay to discuss things. But please do so in a way that
allows improving our software. Just saying "HIMEM is so bad, you
cannot use it in a production environment at all" (by the way,
I did use it in one more than a year ago and my boss was happy
with the results) just causes bad mood, not improved HIMEM.
Eric
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
