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 Jack E-mail, Fresno, California USA, 11.06.2010, 21:42

>> Unneeded for UIDE ... Eric Auer's DEVLOAD that can load it at any time.
>
> Personally I tend to like avoiding external helper applications if I know
> I can do something without them. Indeed I agree with DOS386's comments
> re: device loaders being a "hack", a useful hack at that ... but if there
> is a better way of doing something ...
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. Many FreeDOS
users would argue "heatedly" with you, since without DEVLOAD, they couldn't
put most of UIDE's logic (especially its faster /P binary-search tables) in
the HMA. FreeDOS does not make HMA available until after AUTOEXEC begins.
Also, if DEVLOAD runs so well, why should I and others need to add the same
logic in our .SYS drivers?? "Counter-productive", says I!

> Concerning .SYS device drivers I also forgot about the "next driver
> seg/ofs" field values having the annoying default values of FFFFh which is
> an invalid op-code combination (???? DI) thus preventing a .SYS file from
> being a .COM file. Duh!
The reason is that an FFFFFFFFh value denotes the LAST driver in the DOS
driver list. Re: changing how I document that area, you also noted that
device-drivers are not straight forward -- as one needs much knowledge to
write drivers, little reason for me to change my comments on such a basic
header field.

> So obviously if a .SYS device is a character device driver only using the
> init function then in my "flexibility" book it makes sense if that device
> driver is also available as an installable EXE driver ...
UIDE is not such a driver. It is "character" in its handling of Int 13h
BIOS I-O. But it is also "block", which explains its attribute bits, to
handle CD/DVD requests, which require a "block" driver.

>> logic, and its common data. As I noted in this thread to Rugxulo, are
>> people THAT "desperate" for memory that only 944 bytes really matters??
>
> :) 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
in upper/DOS memory (that I spent YEARS achieving!) why don't we all "Be
Happy" with UIDE's design and forget "unloading". For 944 lousy bytes,
that is also "counter-productive".

> It still amazes me every day when people turn on their computers and they
> just "work" considering the significant number of people involved in
> producing their various parts over the years, the number of
> mistakes/flaws.
It amazes me even more that today's 4-GB PCs in fact do LESS work than the
16K mainframes (1966-1969) or 64K mini-computers (1969-1987) that I worked
with in the past. When Apollo 13's fuel tanks exploded in 1971, and they
had to use only the LANDER's engine to arc around the moon, their on-board
computer did all the calculations and "Got them HOME!" alive! GUESS just
how much memory their computer used -- "Would you believe" 64K?? Today's
PC computers are the most-successfully OVERSOLD BULLSH*T in man's history!

>> since UIDE was not part of the original DOS system and is not absolutely necessary, despite its speed or performance.
>
> You write excellent software Jack as does Bret. Sure you've had a
> difference of approach here. But having studied both of your programs at
> length now and taken the time to see the comments and thoughts that have
> clearly gone into both I would urge you guys to put aside your differences
> and seek out middle ground in terms of improving flexibility - perhaps in
> 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. The ideas of UIDE supporting
"removable" HARD disks or "re-entrant" Int 13h calls, as it would have to do
for Bret Johnson's "workaround", are in my opinion NOT viable but RISKY, and
they would require a LOT more logic in UIDE for it to remain SAFE!

>> ... but my drivers aren't [absolutely necessary]. In their minds, that
>> makes UIDE a whole lot more "suspect", and so I MUST be cautious.
>
> Re suspect - *You* must be cautious or or users? 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.

>> MSDOS.SYS and COMMAND.COM in fact ARE absolutely required,
>
> With the exception of a few fairly "rare" embedded/custom DOS versions
> with COMMAND.COM specific hardware code I've never known it to be
> absolutely required ...
A "default" processor in-between executing DOS programs is necessary. If
not COMMAND.COM, some equivalent is still required. So for the "average"
users who do not play-games with alternates, I said COMMAND.COM instead of
being more general.

>> Also, I want UIDE to be "generic" and run across ALL variants of DOS,
>> and that too requires caution.
>
> Absolutely, I think DOS variant compatibility is a good thing to aim for.
Then it should be obvious why UIDE uses such a simple ".SYS only" and "Int
13h only" design. Anything more complex WILL get me into problems that I
do NOT need!

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

Post reply
 

Complete thread:

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