Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

"Black Box" Approaches. (Announce)

posted by Arjay, 19.06.2010, 22:27

> >> It is now obvious USBDRIVE will never call UIDE for caching.
> > Watching this unfortunate situation deteriorate further saddens me ...
> And me, whether people believe so or not. 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 particularly as to be very honest I haven't wanted to take sides, regardless that I currently know you better than Bret.


> 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. As I have said before I don't believe anyone should be able to blame someone who has gone out of their way to "protect" data. If you have a fault here it is that you are over cautious but when it comes to protecting peoples data it is a quality that I admire, however I have also noted Bret showing similar concerns but from a somewhat different angle.
So I respect you both for being cautious even if you may not be in agreement.

> If people say they are, I will go back to using
> capital letters -- a lot of them!!!!
 Interestingly I learned from watching the BBC programme The secret life of the Motorway that interstate/autobahn/motorway road signs use a mix of lowercase and uppercase as this has more of an impact than just uppercase! So with that in mind perhaps it is just best to avoid CAPITALS :)


> Well, many in this thread have been talking 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!"

> However, do consider this --
 Ok.

> The "UIDE black box" was complete, running well, and had no outstanding
> "bug reports" of which I was aware.
 Ok. Having seen your QA/careful time taken on an update I can appreciate this.

> 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.

> 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 as time goes on, e.g. more people retiring having more spare time, dusting off past interests.

> ever may, with the dearth of DOS driver development,
Well aside from cache drivers in particular remember there are at least 3 other people (in fact I think it is likely to be 4) on this forum who have written device drivers in recent times (i.e. 2005+). So it's not that dearth.


> I was perfectly willing to state in UIDE's documentation that cache-
> units 56 to 63 would be reserved permanently for USB, same as 48 to 55
> are for CD/DVD drives.
 To be honest on the risks of this particular point I do not know enough in terms of how this could be handled to comment. So I won't comment on this point. As you can see elsewhere I have been brushing up again on drivers, not only to understand this situation better but also because I still believe SYS drivers to very much still have their place in addition to TSR programs.

Where I feel I have been wrong in my earlier comments is thinking it makes sense to have combined TSR/SYS files. That said I still see the benefits of them and if there is some good coming out of all this, it is in the SYS driver sources that have been shared and discussions re SYS driver writing.


> That has been continuously noted as being (A) unacceptable, which is his
> choice and not mine, (B) dangerous, with which I disagree since only two
> people are involved, and (C) something "I MUST!" fix or eliminate.
Ok,
A) As above I have too little knowledge on this point/issue to comment.
B) You are assuming 2 people which is a bad thing IMHO as there may be others you are unaware of.
C) Ok, I can however see that you have done this re protecting data. i.e. you've made this decision in good faith. I might not agree with you on the removal of the external interface but I can at least see your logic. So re the removal of the UIDE's external interface I am happy to agree to disagree.

> As this became an unceasing and insufferable issue, fine: I eliminated!
> [snip]
> know that I did indicate a "total solution" for all this to Johnson Lam,
 Ok, Fair enough.

> A "wrapper" around UIDE could have been written.
 Indeed.

> 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). I also remember thinking that if TSR's were written correctly AMIS didn't matter. Indeed I have just noted that someone has put the following comment on Wikipedia re AMIS: "...The proposal never gained a widespread traction among programmers in its days. It existed alongside several other competing specifications of varying sophistication..."

This I agree with in the same way I didn't always bother to give back time slices in some code depending on what I was doing it just wasn't necessary, i.e. if a loop ran only a few times for a very short time what was the point, there was however a point if a loop ran continuously. That said in the one program that I wrote that looped so much it burnt my name into several CRT screens I never time slicing either. Why? Because it didn't need it :)


> In support of AMIS/IISR, the "wrapper" could have been the sole point of
> call to UIDE's external-entry logic, thus permitting UIDE to "stay where
 Indeed and this is why I felt I had to voice my disagreement when you removed this feature. However it sounds like you've done so to draw a line on all this on your side. I can understand but to be honest I still feel this is a step backwards.

> it was" in memory, then permitting the "wrapper" and other "new" drivers
> to re-arrange their AMIS/IISR interrupt logic however they desire.
Exactly.

> for the many "unloadable TSR"
As someone who rarely bothers to unload TSR's I understand you here. However at the same time I appreciate that I do things differently to most other people so I often implement things for others that I would never use myself.
So if I was writing a TSR today would I include an unload? To be honest if it was only a few bytes I probably wouldn't, but if several K then I would.

> Same as this morning's post on Bret Johnson's forum about my "psychics"!
 Yes, I did note that comment but choose not to directly reference it here.

> 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.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22649 Postings in 2111 Threads, 402 registered users, 830 users online (0 registered, 830 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum