> [snip]
> Also, I have never heard of a LILO "tsr",nor can I imagine how/why any dos
> programs would bypass or conflict with LILO.
> Win95 doesn't even recognize my master hdd, so there!
> ---
I encountered this "way" back with Linux v1.2.8 on a then recent Slackware release
(last summer ?) Don't think v1.2.13 was on sunsite yet. Now using RedHat v3.0.3
release, modified w/Linux v2.0.0, etc. (Penquin hell, try peregrine. This thing
flies)
The "tsr" to which I refer is "/boot/any_d.b".I recall looking at the source file
(in the lilo tree, don't have source installed at moment), and also chasing thru it
w/messy-dos's debug. Curious as to how it worked. This "huge" file (I think then
was 512 bytes) hooked int 13h, the bios disk interrupt. It examined the drive
select byte, and maybe toggled the low bit, before chaining to the previous handler.
ie. dos thought it was on the 1st drive (0x80) when it was really on the second
(0x81). Maybe I should have referred to this file as a device driver ?
The "conflict", strictly guessing, was w/some program that accessed the hardware
directly. What it (and dos) considered drive c was physical device 0x81, not 0x80.
so going direct (instead of using int 13h) would access the wrong drive, which
was what I was seeing. No, don't recall which program(s).
Again, this was some time ago. File is now 204 bytes. Don't know what may have
changed. May be completely different now. SWAG, lilo v0.14 ???
Re Windoze 0.95 - after *34* re-install's on 4 different hardware platforms,
including one where it came "pre-installed", it out-stubborned me. I'm sticking
w/Linux. (Well, maybe a few dos games). Don't see why the company's software should
with itself.
Big "problem" using Linux tho. I can no longer justify taking un-scheduled break
time by claiming "the computer is busy". Drat, shux, and such.
So there back at ya' :-)
--
Cheers,
Roger
by