NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/binaries/ibm/pc/archives/3550

Internet Message Format | 1992-07-21 | 5.2 KB

Path: sparky!uunet!mcsun!uknet!ox-prg!emerald.comlab!ptb
From: [e-mail] (Peter Breuer)
Newsgroups: comp.binaries.ibm.pc.archives
Subject: Re: Review of The Last Byte (again)
Summary: Just reassuring you all about  review procedures
Keywords: last byte, lastbyte, review
Message-ID: <[e-mail]>
Date: 22 Jul 92 16:25:29 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter Breuer)
Followup-To: alt.flame
Organization: Oxford University Computing Laboratory, UK
Lines: 96

In article <[e-mail]> [e-mail] writes:
>1. I am a registered user of ver 1.20 (the review was on 2.02). I used
>it for several months on a 386SX and Windows.

Hi Darrel - nice to hear from you again. I told Dan Lewis that his many
satisfied LASTBYTE customers would leap to his defence!

I just want to offer some reassurances to you and netland on the
procedures employed for the review. First of all, Dan (the LASTBYTE
author and vendor) has checked two versions of the review, and I have
incorporated his comments. I am not saying he agrees with it, or that I
have got everything technically right, but I don't think either of us
feels there is a major conflict. We have probably exchanged about a
dozen letters over 2 weeks prior to posting to cbip.a, and
every one of his - at least - has been informative and helpful. Dan has
not attempted to correct my judgements, but I have altered some opinions
in the light of knowledge I gleaned from him. I would recommend that reviewers
generally contact software authors for technical advice with their review,
and as a matter of courtesy. I am afraid that I neglected to pass the
absolutely-the-final version to Dan for comments, but I didn't feel
that I had added anything substantively new to it since the last time
he had seen it - just made corrections following the information he
supplied.

I haven't kept a complete record, but I have certainly tried over two
hundred configurations.

>2. I had no problems with TLB and Windows 386enh mode.

I wish I knew why my setup doesn't work. Dan has looked at the memory
dump and can't see why it doesn't work for me either. There may be a
glitch  still remaining in the driver for my chip? But indeed, TLB is
_supposed_ to work with win386enh, and you are right to affirm it.

>3. I like the extra utilities and the complete documentation.

I agree to disagree.

>4. The price comparison with an extra 1M of extended memory is somewhat
>misleading. Perhaps the reviewer means to say:
>  If EMM386 is an acceptable way to provide UMBs, then an extra meg
>  of extended memory is more cost-effective than TLB.

Indeed I did mean that. I already have an UMB supplier
(HIMEM,EMM386,UMM.SYS, QEMM, etc.), so I gain 96Kb of extended memory
from TLB at a cost of $29.95. The 96Kb is what I can now release from
duty in serving UMBs. 1M extra extended memory doesn't cost $300 - but
TLB comes with useful utilities too. (I agree that this comparison is
highly unfair and misleading, but it is, nevertheless, illuminating).

>5. [...] the review may leave the
>impression that hardware EMS is required to obtain UMBs. TLB can
>provide UMBs on any 286 or 386 with shadow ram and a supported memory
>chipset [...]. emm386 can provide UMBs on a 386, but there are some penalties.

Indeed. Dan urged me to point out that 8086/286/386/486 machines are
all served by TLB, provided they have a supported shadow ram
controller. Hardware expanded memory will usually do if not. Apologies
if I didn't make this clear.

>6. The fact that the "hole" feature is not in the unregistered
>version was documented in ver 1.2.


Yes - Dan read my complaint that way too! I didn't mean that it wasn't
documented, only that the _consequences_ weren't. If you use the
shareware 32K of high ram to suppy UMBs - and manage to supply and use up 32K
of bankswitch memory too - then there is no way to use HIGHMARK/HIGHUNDO,
because they will need extra memory. To some extent the situation
persists into the registered version, because HIGHUMM, unless
`restrained' claims all memory for UMBs, leaving none for marks. I.e.
the TSR marking routines don't use the UMBs supplied by HIGHUMM.
Confused? You should be. I was. I should point out that one can't use
HIGHMARK anyway in the shareware version, because only two utilities
are allowed to be loaded, and you are likely to use those up with a
HIGHDRVR (for HIMEM.SYS or whatever) and HIGHUMM (for UMBs). If you
don't, say, use HIGHUMM, then there are no UMBs for TSRs to go into,
hence no real need to use HIGHMARK to mark them. I think the
restrictions in the shareware version could be relaxed _a little_!

> The use of F0000 may be
>machine-dependent: I could use this area on my machine.

The F000 area on my chip is not read/write, and hence cannot be
utilized. This is a machine dependency.

BTW. The HIGHUMM subject is where I _did_ get the facts a little
wrong. I thought that I couldn't restrain it to use only a portion of
available highram, but I didn't try hard enough, and underestimated the
space required by certain overheads. Try it for yourselves.

All the best. I live in hope of starting a flame war of the quality of
that on sci.research.careers at the moment! Retune now for the final
episode.

Peter <[e-mail]>