DOS ain't dead

>> ... I was not put on this Earth to cause problems -- but I will respond
>> to problems others throw at me.
>
> Having swapped several private emails with you on other topics other than
> from DOS and got to know you better as person I do genuinely believe you.
> However rather than privately emailing you I felt it was better to be
> "open" in some of these discussions ...

Understood, and my Thanks.

>> They are welcome to try. If they do, and USBDRIVE is permitted to use
>> DOS and UIDE hard-disk logic for "removable" drives, resultant problems
>> will not be my fault.
>
> That is a good approach.

Actually, a sad one. I still believe many people will suffer crashes.

>> Well, many on this forum have been speaking about "unloading" drivers to
>> save memory. Saving 111 bytes permanently is one class of "unloading".
>
> A very clever and witty reply from yourself. All I can say is "Touché
> sir!"

Merci, Monsieur.

>> The "USBDRIVE black box" is noted as being not-yet complete, and to deal
>> with it, I was asked to make changes I felt were not necessary.
>
> Ok and as the maintainer for UIDE this is a perfectly "acceptable"
> response as no programmer should feel forced/required to do anything
> with "their" work.

Tell that to Bret Johnson.

>> Only 2 people -- Bret and me --
>
> This I have more of a problem as you are assuming this to be/always be the
> case. I am expected to see over time a "reverse" in DOS ...

I doubt it. Even if so, few will go back to DOS and write device-drivers
needing caching support. "Only 2 people" should be true for a long time.

>> If you wish to talk of "black box" approaches, I will let you GUESS with
>> whom you should speak first.
>
> Well I am happy to talk with Bret to hear more of his side as someone
> genuinely interested in trying to help you guys find some middle ground
> in a constructive way. I think I have been failing in my attempts so far
> but at least I've been trying despite my own faults.

There was no middle ground. As I got tired of this being an issue, and as
I found valid technical reasons NOT to allow USBDRIVE "messing up" UIDE, it
was my decision to eliminate external-entry logic, end this issue, and keep
USBDRIVE out! Little more you could have said or tried, same as me.

---
(Account disabled on user's request.)

Let me respond to several comments in this post this way.

Jack, still to this day, does not realize how good of an idea his external interface is (now was). It simply needed some "fine-tuning". His (paraphrased) statements of "nobody will ever use the interface anyway, so I don't need to fully document or automate it" ended up being a self-fulfilling prophecy. Jack did not even give himself the credit for what he did.

Once I started investigating it, I saw the potential for several uses of the interface besides even disk caching. That's why I was insisting that Jack "automate" the interface. Of course, given Jack's cautious attitude, he may have considered such "non-standard" uses to be abusive or unsafe, and eventually dismantled the external interface, anyway. It was certainly possible for me (or someone else) to build a "wrapper" around UIDE to manage the handle numbers, but I still feel that always should have been UIDE's own internal responsibility.

Once Jack saw the word "ludicrous" and incorrectly thought it was being applied to him rather than to UIDE's non-automated interface, the conversation instantly turned to a downward spiral of anger and resentment from which it never recovered. I was doing my best to respect Jack's wishes to "leave him alone", but felt I needed to respond to some of the accusations he was making on this forum. The entire situation certainly could have been handled much better, from both sides.

My further opinion, FWIW.

> > The "wrapper" could have contained allocate/deallocate entries for cache
> > unit numbers. The "wrapper" could have contained the "AMIS/IISR" logic
> > that people who want "new style" drivers so urgently desire -- I do not.
> This I can understand as back when I wrote a number of TSR's (mostly
> internal home/work projects) I studied AMIS and personally felt that it was
> overkill which added complexity that I didn't need (at least that's what I
> felt at the time).

Is AMIS overkill? Perhaps, but it is the only viable option available that I know of. As I stated earlier, the only other alternative to AMIS I've ever seen documented in TesSeRact. While similar in concept to AMIS, TesSeRact had one insurmountable problem -- it continued to use INT 2Fh, which contains all of the Microsoft baggage that comes along with it. I know Wikipeida talks about "several other competing specifications", but I've personally never seen any of them. Maybe the only reason AMIS seems to have "won out" is because it is supported by Ralf Brown in the infamous RBIL. Whatever the history, AMIS seems to be the only viable choice today.

The reason programs use IISP and AMIS is not so much for themselves, but rather for other programs, and ultimately the user. AMIS/IISP allows other programs to insert their interrupt handler "before" yours if they want/need to, even if you were actually installed first in time. Likewise, it allows another program to be uninstalled even if you were installed after it was and are both using some of the same interrupts. In other words, the protocols allow drivers and TSR's to "play nice" with each other, which ultimately benefits the user.

It is true that AMIS requires a few hundred bytes of resident overhead, but I personally believe it is well worth the cost when compared to the benefit it provides the user.

I don't think it is ever a programmers right to decide that a particular programs functions or services are so "indispensable", or that is uses so little memory, that the user will never want to remove it. That ultimately and always should be the users decision, not the programmers.

> I also remember thinking that if TSR's were written correctly AMIS didn't
> matter.

The only way that would be true is if a particular program only used interrupts or hot-keys that no other program would/could ever possibly use, which is usually impossible to guarantee. I think the only way to guarantee something like that would be if the program didsn't intercept any interrupts at all. I don't know of a "useful" device driver or TSR that doesn't intercept any interrupts, though it's possible there is something out there.

> > > notice in passing that [FreeDOS IBiblio] are now very behind on your
> > > recent driver releases ...
> > They always were. FreeDOS is a "volunteer" project, and there are not
> > enough volunteers to go around.
> Somebody added it recently (thanks!), so it's there now.
> drivers-2010-06-16.zip 29-Jun-2010 02:12 129K
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/udma+drivers/

Thank you to whoever did add a newer version to Ibiblio. Note: There have already been 2 further releases since the 16-June (not yet on Ibilio) with the latest drivers.zip released 2 days ago (documentation updated).

> Well it does happen. Indeed I am aware of it happening with developers. I
> have also walked away from several technical groups (non-DOS) due to very
> similar disputes. So I know all too well that sometimes people just need
> to say "enough is enough" and move away either to take a "short" break or a
> break for good. I have done both, so I feel I can appreciate anyone doing
> the same.

If you find pleasure in your own and independent work, and you also think it may be beneficial, making you proud, you never walk away from it. You did refer here to team works, of which your contribution was just a dependent part and where you lacked the total power of decision. And how frustrating it is to be bound to concede, when you think your ideas better, or to accept, when you think their ideas worse, but still to have no other choice but to say "enough is enough" and to leave.

> Peace can only achieved when people put aside their differences. For
> example 20+ years ago I wouldn't have ever imagined that I would have been
> able to appreciated visiting Bucharest, Cluj, the former GDR and many other
> places - had many people not put aside their past differences for the
> greater good.

Putting the differences aside can bring only loss of identity, of creativity, of ambition and of self-esteem, because as long as these qualities would exist people will disagree and will fight each other. But in fact it is not to put aside the differences what, purposeful or not, the preachers of peace aim at, but to put aside any difference against their message and to obey unconditionally to their views. This is nothing more than a war carried under the mask of "peace" and consequently pure hypocrisy.

---
Glory to God for all things

> del

As I wrote in the past in a PM to another user of this excellent forum, unfortunately it lacks two items which I consider very helpful: a quiz and a poll. A point-rewarding quiz in order for us to check or improve our technical knowledge on DOS, and an in-point-poll, so that we may have our opinion pulse taken concerning the important DOS issues which appear.

---
Glory to God for all things