Hi Eric, at first thanks a lot for your answer.
Eric Auer schrieb: > Hi all, > > my excuses for the length of this mail. I hope at least > Norbert and Blair will read all of it :-). I read all of it ;-) > 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. I never wanted to say, that there's nothing good about Michael's memory management apllication. I only wanted to underline that it is unusable at the moment for me, because it crashes a lot on different types of hardware. But as I already answered in my other posting I'm going to take the time and test his newest releases in corporate environment and give detailled error reports. > [...] > Sorry for the miscommunication about the FreeCOM / diskimage > issue, Norbert. Explicit and detailled bug reports are > better than blaming people for bugs in general. Right, I never give bug reports to blame somoeone. My intention is only to make the software better. And that really has nothing to do with personal flamewar. >[...] >> 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. You are right. But flamewar about qhimem is as old as time. But why?!? Different people always have different opinions. That's life. And everyone of you has to respect this. And I think none of you will say that qhimem is a bad product and because of this Jack's memory manager has the right to be a part of freedos, again, closed source or not. That really doesn't matter. >> 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 ;-). No access to irc on work, sorry. But I really would like to do so. >> 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 know, but that's what I expected to hear and that was my intention. Perhaps it is a good thing to have competition back between qhimem and himem-emm386. But please in another way than always saying "stupid piece of software"! > 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, ... Not right, because as a normal user you don't have to care about the chipset you are using, because UMBPCI automatically checks and only gives a message if an unsupported one is found. > ... 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...). I can remember that emm386 didn't work on a intel based board with 845g chipset while the microsoft product did. But I give it another try this week. > [...] >> [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. As I said before, I didn't. But I will. > The only advantage of QHIMEM is that it uses even less DOS memory. I think the problem is not the himem part. I believe that all problems refer to the emm386 portion. > 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. Just forget the statement. I only wrote this to remind Michael that there is other software, that has good characteristics, too. >> 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 Thanks for the url. I will do testing with this release. > [...] >> 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. Sorry, have a good time then ;-) >> 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), QDMA also doesn't work with Symantec Ghost when used on a SATA-System in IDE emulation mode by BIOS. > [...] >> 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. See my answer to Michaels posting. Norbert. ------------------------------------------------------------------------- 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
