Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Seeking the middle ground ... (Announce)

posted by Arjay, 12.06.2010, 01:12
(edited by Arjay on 12.06.2010, 02:08)

> I do not view DEVLOAD or other such .SYS file loaders as any sort of
> "hack" as they provide a service that DOS designers never imagined.
 True, I guess they can be viewed like other DOS enhancements we can all be grateful for like DOS extenders, CD-ROM drivers and even the IBM-PC itself :)

> Many FreeDOS users would argue "heatedly" with you,
Hopefully not! Still to be clear I was NOT not saying such hacks are a totally a bad thing, technical fields are moved forwards by people like the folks who frequent this forum working out how to constantly push things in all directions to the point that often as you know such "hacks" become "standard". With regards to DEVLOAD I guess you are right command-line .SYS device loading can be viewed as a standard option. And if it ain't broke....

> FreeDOS does not make HMA available until after AUTOEXEC begins.
 Interesting I wasn't aware of that for several reasons: 1) For years I used other non-FreeDOS kernels. 2) I haven't bothered with HMA for years as most of what I have done with DOS hasn't needed me to even need to worry about it.

> Also, if DEVLOAD runs so well, why should I and others need to add the
> same logic in our .SYS drivers??
 Ok, as above I see your viewpoint but was also being the devils advocate here. On a personal note in the past I used DDU/DDL which on the "rare" occasions I needed to load drivers from command-lines they did their job, thus I never sought out or indeed ever became aware of DEVLOAD. If I have/had it anywhere it was probably as part of a larger archive (like Simtel) which I mirrored. Indeed the first time I can remember hearing of DEVLOAD was on here.

> "Counter-productive", says I!
 Ok.

> The reason is that an FFFFFFFFh value denotes the LAST driver in the DOS
> driver list.
Indeed like Zbikowski's "Z" on MCB's.

> Re: changing how I document that area,
 On this point I was simply suggesting making that part of your source clearer to folks by better showing the 2 values as segment/offset "filled in by DOS".

> you also noted that device-drivers are not straight forward --
Yup, it's been many years since I last compiled one. Well actually that's not now entirely true as I recompiled from source all of Bret's code the other night and was impressed when I got zero complaints from a86/a386.

Anyway somewhere I have a SYS driver I wrote to force a headless PC to switch back to color VGA from mono VGA, and 1 or 2 several others. But nothing as complex as what you/Bret have written and I'm rusty after a 15 years absence.


> > driver is also available as an installable EXE driver ...
> UIDE is not such a driver.
 Yup, hence I corrected myself in case anyone else reading what I wrote earlier (which no one else corrected me on) read it in a way where this all it sounded easier to do than it is. Thx for confirming what I was suspecting!

> > :) Well I guess it depends on the circumstances ...
> I agree, and since there are really few DOS drivers that load in the HMA
> and so "leave behind" only 944 bytes of stack, data, and entry/exit code
 Well you could keep use the stack to clear bytes and push an exit jump, e.g:


org 100h
mov sp,0110
mov ax,20cd


Just kidding.... ;-)) [and yes I know that 2 line example is very "bad"...]


> in upper/DOS memory (that I spent YEARS achieving!) why don't we all "Be
> Happy" with UIDE's design and forget "unloading".
I find the quickest way to unload is a reboot... (or overwriting memory.... :)

> For 944 lousy bytes, that is also "counter-productive".
 :)))


> It amazes me even more that today's 4-GB PCs in fact do LESS work than
> 16K mainframes (1966-1969) or 64K mini-computers (1969-1987)
Probably true of the operators too.... far too many "cut and paste" folks !
Ah yes 1401 et al - still this is a DOS forum, so lets keep MF's to pvt msgs:)

> "Would you believe" 64K??
 As we both know 64k is a lot of space.... :) An interesting point of note here is the fact that the first DOS machine only had 16k. I used to own a PC with 256k but sadly loaned it out to someone from whom I never got it back :(

> > a black box kind of way?
> I shall "defer" that issue to others who know and understand what I
> consider a more "viable" and more SAFE approach to be.
 Ok

>> To be honest I think you need to really put any onus with the end
>> users rather than your good self.
> No, in fact it must be ME who is cautious, since "unenlightened" users
> WILL blame UIDE and me for other problems, and they will do so even
> BEFORE I get a chance to explain or to defend myself.
 I also realize you've been burnt several times in the past but rest assured there are those of us happy to defend people and whilst also seeking the middle ground where appropriate. Sadly though I think it is fair to say "unenlightened" folks as you put it will always aim to burn others for the most silly of reasons. e.g. I got burned in the past by quite a number of folks for taking some PC screen captures with a digital camera. Fairly trivial point but some "unenlightened" folks didn't realize that due to what I was taking a picture of that I didn't/couldn't possibly have any screen capture software installed on the PC in question. Enlightened people understood straight away. Obviously had I had easy access to another PC with a VGA2PAL adapter and capture board I would have wired 2 PC's together to take the screen-shots but people forget that not everyone has the same resources.


> A "default" processor in-between executing DOS programs is necessary.
> If not COMMAND.COM, some equivalent is still required.
Well FreeDOS at least handles a missing shell in quite a neat way allowing you to run a program and then return back to the missing shell prompt before then allowing end users to run another program. Indeed with that in mind I am planning to deliberately allow a (re-written) RJDOS to be fully "exited" in a certain way. Just in case someone (e.g. Rayer) wanted to use feature.

> So for the "average" users who do not play-games with alternates,
> I said COMMAND.COM instead of being more general.
 :)

> Then it should be obvious why UIDE uses such a simple ".SYS only"
And indeed it is. Thanks for directly clarifying re the block aspect as well.
We've also avoided discussing the joys of cooked vs raw.... as well :)

> Anything more complex WILL get me into problems that I do NOT need!
 Indeed I understand... especially with those damn neighbors of yours... grrr!

Thanks for an interesting discussion which has made me think more about how some of my long term work can hopefully help narrow down some DOS issues.

Post reply
 

Complete thread:

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