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, 11.06.2010, 19:29
(edited by Arjay on 11.06.2010, 20:07)

> > driver / loadable TSR's.
> Unneeded for UIDE, given 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 in this earlier LOADSYS | DEVLOAD | DDU discussion re device loaders being a "hack" - a useful hack at that (like PING, Mode-X etc) but if there is a better way of doing something that avoids the need for hacks then surely that is even better? In a "gentlemanly" fashion I am happy to "agree to disagree". I have however also done some reading to better understand/remind myself re drivers:

Firstly my humble apologies to both you and Bret as my subsequent "refresher" reading (mostly my well thumbed copy of PC Intern) and studying of your respective sources has highlighted to me that I made a few fundamental errors in my earlier comments (as I have not dealt with DOS drivers for some years and have thus forgotten various key points over time, e.g character vs block).

I also reminded myself that installable .EXE device drivers are effectively TSR's "acting" as "character" devices and only supported device function 00h (initialization). I am partly paraphrasing the PC Intern's author on these later points rather than quoting these as facts - or to put it another way I have read many things that say you can't do that but then found the opposite.

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. Doh! Still related to that I was interested to note how UPX (which I spotted you use on XMGR) carefully preserves the 3 first fields of the .SYS header (ofs/seg/attr) whilst still allowing packing including even the last field (device name in case of a character device) which I thought was neat :)

On this area I think that area of UIDE.asm would read better written as:

@       dw       0FFFFh         ; Offset addr to next driver  (filled by DOS)
        dw       0FFFFh         ; Segment addr to next driver (filled by DOS)



Anyway I have reminded myself combined drivers are not a straight forward as I "vaguely" remembered. I also have remembered config.sys install came about in a latter versions of DOS. DOS 5?? (along with himem.sys?) or was it v 4?

As mentioned earlier I believe as much flexibility as possible is always good,
however programmers need to draw lines somewhere, e.g. UIDE is already 386+

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 (via CONFIG.SYS or AUTOEXEC.BAT) without the need to rely on any additional programs.

However my dusting off of this area and review of UIDE has highlighted that UIDE uses the attribute C800h which as binary 1100100000000000b decodes I believe as follows:

1 - UIDE is a character device
1 - functions 03h-0Ch are supported
0 - function 10h is *NOT* supported
0 - reserved
1 - functions 0Dh-0Eh are supported


Correct? According to what I have read function 00h (drive initialization) only allows function 01h to 0Ch to be called as DOS has not yet finished initializing as that point. In otherwords if I am reading this correctly it means although UIDE is a character driver it can't easily become an EXE based driver as it supports other functions. I also appreciate IOCTL comes in etc.

Obviously there are other ways of loading device drivers from DOS (and doing these things) but I'm just looking/working to understand UIDE as it "stands".


> There would be few risks unloading UIDE, as it "hooks" only the Int 13h
 Yes, noted in the source which I have now studied more than I did previously.


> 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 once had to write a menu system in assembler just because a new network stack on a 80186 network left no memory for the earlier DOS menu shell to be able load an app ;-)
However that was with DOS low mem. I can't say I've experienced similar upper memory problems but I can imagine them from what Rugxulo has written.

Although I like flexibility I also appreciate that you can't please everyone.


> Computers are among VERY few "black and white" subjects on earth. They
> either work 100%, or they "Fall on their NOSES!", with not so many "minor
> bug" situations in the middle.

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.

Indeed having also read/studied many books/texts such as Fatal Defect - chasing killer computer bugs - in the past I would have tended to have fully agreed with you (particularly around Y2K!!). However over time I have realized it simply is not worth trying to dot every "i" and cross every "t" even when it comes to software reliability and that there is a careful balance between perfection for reliability and perfection for the sake of perfection. I have certainly been guilty of the later in the past myself.

> I hope none of you will be offended when I say there ARE "users out there"
> who WILL tend to blame drivers like UIDE for all their problems,
Well firstly I think it is important to remember that we have all been users at one point. Indeed back in the days before built-in DOS help existed and flashing warnings. Due to not bothering to fully RTFM a large manual (at that time); I discovered first hand just what FDISK could do the "hard way" only a few hours after getting my own PC and in my excitement wanting to split a 50Mb drive into a C: + D:... The "delete existing partition" warning is now somewhat clearer now then it was then ;-) Did I blame MS? No I didn't.

So we can all be idiots at times. Even some of the worlds smartest people really lack common sense at times. I think people can only go so far helping to protect others from themselves. In the case of programming I would say as long as you put very large warnings (disclaimers) / hide "dangerous" options away then at least you can say you've done your best to protect "end users" from themselves. So that if they screw something up they really can't have any come back - as you've taken time to warn/prevent self harm etc. That said it is shocking the number of people who just act upon emails saying "delete the file with a bear icon..." :) Still my point is you can only do some much to protect people from themselves. I have thus come to the conclusion that it isn't worth disadvantaging the majority for the sake of a few people who would jump off a cliff regardless of the number of signs that are put up.


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


> but my drivers aren't. 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.


> 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. Indeed there are times when removing COMMAND.COM's from the picture can be very helpful in testing. e.g. Someone can load/install drivers via CONFIG.SYS and then load straight into "an app" instead (e.g. via SHELL= or by renaming it to COMMAND.COM if like me you often don't even bother with CONFIG.SYS either!)

So for people experiencing problems with COMMAND.COM shells (e.g. Freecom...) they can always rename their app to COMMAND.COM and try it. If they need BATch files (yuk) which don't need COMMAND.COM specifics (e.g. DIR) then they can compile them with BAT2EXEC, BAT2EXE, BAT2COM etc and then renaming the resulting program to COMMAND.COM thus allowing them to do many of the fun things DOS batch files allow people to do still without needing COMMAND.COM.

Note: From memory the documentation for those BATch compilers all talk about it not being a good idea to load TSR's via the above programs (for obvious reasons) but to be honest back when I still used these programs I never had a problem loading device/drivers in that way for what I was doing with them.
Not something I would recommend under normal circumstances (unless you know what you are doing) but for testing (or special configs) it can be useful.


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

> "Blessed are the peacemakers",
:)

> and you will get to Heaven before me,
There are several ways of reading this :-) !!!!

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