NetNews Usenet Archive 1992 #16

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / binaries / ibm / pc / archives / 3503 < prev next >

Wrap

Internet Message Format | 1992-07-20 | 22.4 KB

Path: sparky!uunet!mcsun!uknet!ox-prg!emerald.comlab!ptb From: ptb@prg.ox.ac.uk (Peter Breuer) Newsgroups: comp.binaries.ibm.pc.archives Subject: Review of The Last Byte memory manager Summary: Review. Keywords: review lastbyte last byte memory manager Message-ID: <4077@inca.comlab.ox.ac.uk> Date: 21 Jul 92 12:18:33 GMT Sender: news@comlab.ox.ac.uk Reply-To: ptb@prg.ox.ac.uk (Peter Breuer) Organization: Oxford University Computing Laboratory, UK Lines: 432 LASTBYTE.RVW Review Product title: LASTBYTE Version: 2.02 Author: Key Software Products Directory: simtel mirrors: sysutl/tlb-v202.zip Reviewer: P.T. Breuer <ptb@uk.ac.ox.prg> Date of review: 13/07/91 Product description: memory manager + utilities Cost: $29.95 for registration. Review Equipment ---------------- Machine: WE NBL 36X16, VLSI '320C chips Processor: 386sx CPU Clock: 16Mhz Memory: 3M extended/expanded Display: VGAM Operating system: MS-DOS 5.0, 4DOS 4.01 Other hardware: n/a Other software: QEMM 6.02, HIMEM.SYS 3.00, EMM386.EXE, WINDOWS 3.0a, STACKER 1.0, HYPERDSK 4.31, BOOT.SYS Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation 3 Ease of use 2 Help systems 1 Compatibility 4 Company Stability 4 Support 4 Documentation 3 Hardware required 3* *I borrowed this format from Performance 4 comp.virus reviews, and I Availability 4 take a high `hardware' score Local Support ? to mean `few requirements'. About the package ----------------- Lastbyte is a set of RAM-extending utilities. It uses expanded memory or shadow memory to fill in as upper memory between 640K & 1M, which then becomes available to DOS and other programs. Installation ------------ I ran the INSTALL program in the package, which invokes the CHIPSET checker and suggests a DEVICE= line for CONFIG.SYS. I chose to abort the routine and edited config.sys myself, because I didn't trust it to alter the customized multiple boot configuration utility (BOOT.SYS) I had set up to help with testing - I have had experience of setting up memory managers! If I had not aborted, a vanilla config.sys would have been written on to any bootable floppy in A:. So installation seems safe enough and I liked the install screens. Pop-up help would have been a comfort the first time round, and Key Software should pay more attention to making installers feel safe, secure and well-advised at this stage. They will miss out on a big market otherwise. There is no information on the _consequences_ of a button push, so it is a case of holding ones breath and trusting to the software, and quite a few window-shoppers might bolt at this stage. How it performed ---------------- I see that the last time I reviewed lastbyte (Dec 1991, v1.20), I began "I wasn't very happy with this utility ...". I am much happier this time! Key Software have made great progress both with the technology and with the interface. I found lastbyte 2.02 quite charming by comparison with its previous incarnations, and the technology is now addressing enough different types of shadow ram controller to cover most of the major 386 and 486 machines being built. Mine included - which is what I noticed most! That said, I should get it off my chest right now that (1) I still dislike the dozen different utilities (*1), and the 150Kb+ of documentation. Why is it impossible to make a _single_ utility load as much as itself as it needs according to the command line switches? Even better, the install routine could trim the utility according to the switches, saving on disk space as well as memory space. The monolithic documentation is easy to get lost in, and I had to make a hypertext version for myself before I could begin to see it at all. (2) there is a 32Kb limit on upper memory usage (for UMBs) in the shareware version which makes it quite impossible to test for compatibility and conflicts. I can't load STACKER high (*2), for example, and I am not going to buy until I know I can get both stacker and a disk cache high simultaneously. Key Software, take note. 32K means that no-one who already has a 386 is going to be keen to buy on the basis of the shareware demo alone. This is a major limitation and makes the label `crippleware' difficult to avoid - though one can get some memory gains out of the unregistered version, and those are absolutely free of charge (registering costs $29.95 and buys you up to 384K). --- *1 The many utilities do serve a purpose. Lastbyte enables parts of memory which shadow physical adapters to be used for data (not programs - they might try and access the adapter in their own address space) and the utilities all make good use of this kind of memory (`bankswitch'). No other vendor bankswitches shadow ram. --- *2 No such problems in the registered version. Stacker loads high in an UMB. Apart from these two pet `hates', I cannot complain. Lastbyte simply does the job on my machine, but it is __very__ hard to set up -- not through any intrinsic fault of its own, I suspect. But these remarks do reflect a relative lack of attention in the lastbyte design to the human interface problem, vis-a-vis the technical challenge. Technically, QEMM (for comparison) has a much easier job to do on my machine because it fills in with extended or expanded memory, not shadow ram. But qemm seems infinitely more robust. Why the difference? I have yet to be able to run windows (3.0) in enhanced mode over lastbyte alone, for example. The only way I have been able to is by loading qemm on top of lastbyte - which I recommend as an approach. (Yes - I set all the `magic' switches in system.ini). It feels as though qemm may be applying some extra healing magic for irregularities in upper memory. My problems may be peculiar to my setup, however. Lastbyte is documented as supporting windows 386 enhanced mode, and, as I said, I could do it by pasting qemm on top. I am still a little confused by the documentation on the memory designated `hole memory' by lastbyte. I could not get the HIGHMARK utility to load until I named some holes for lastbyte in the registered version. These `holes' are designated areas (often at the tail end of shadow ram blocks) that lastbyte can use as additional high ram. It seems that I used up my high ram with the UMB provider, so that highmark needed some extra holes in my non-read/write (hence non-hi-dos'able) shadow ram before it would load. But the shareware version has the use of holes disabled and hence I couldn't get highmark to work at all! I can imagine potential customers getting quite angry at wasting a week trying it out! There is a neat utility - HIGHHOLE - which suggests holes to use, but I am not sure if holes are worth the trouble, overall. If they work, then you have gained a few Kb of memory at no cost to yourself. I am still not able to get the supplied EMS drivers to work. Again, I have a feeling that qemm is a more stable EMS manager over lastbyte than the supplied managers, but it would have been nice to have been able to make a comparison. The supplied managers should be more space efficient. Overall, I find that there are very few conflicts with non-windows applications and utilities, but windows in enhanced mode is still a pain, though it can be coaxed into working. Ease of use ----------- (1) and (2) above do make it very off-putting to set up lastbyte. I must have been through a hundred reboot cycles by now, searching the configuration space. But this is not bad as memory manager utilities go. I just prefer the neatness of QEMM's setup, and the simplicity of UMB_DRVR (simtel, etc.). I can think of worse interfaces (I might get sued, so I won't mention them) and I would put lastbyte about 75% _of the way _up_ the usability scale, so do not take my complaints too seriously! It's just that things could be so much better ... Key Software have done a lovely streamlining job, but this is still an iron-age interface, which just used to be stone-age. Can _someone_ please write a decent expert system to help with memory manager installations? Or are PCs + DOS just too much of a mess? Compatibility ------------ The 2.00 version of lastbyte on GARBO, SIMTEL etc. at the beginning of the month hung my machine, and a quick email reply from Dan Lewis at Key Software (weekend, yet!) told me to wait for 2.02, which fixes the bug. That was very good customer support. It seems several glitches got into the bytes with the change to assembler and the all-new organization of the code, and these were fixed in 2.01, which lasted a week before turning into 2.02 with a minor bug fix. 2.02 works fine for me now, and feels robust. I have no reason to believe that lastbyte is not as compatible as it is possible for a memory manager to be, and I ran it with all the systems I listed in the heading of this review. As noted above, I couldn't get the `mark'/`release' memory utilities to work at all on the shareware version. I found that Direct Memory Control's TSR management utilities (DMCxxx, simtel and mirrors) worked perfectly instead. I thought at first that 4DOS did not see the UMBs dispensed by HIGHUMM.SYS when qemm was also loaded, but it turned out that I had the driver loaded before qemm instead of after. There are some advantages to that strange arrangement, and the 4DOS problem is the only disadvantage: qemm sees conventional memory as extending to 800K+, or wherever lastbyte's UMBs stop, which can be helpful. I have experienced some problems with hyperdisk (HYPER386.EXE) loaded high with expanded memory running, but not under extended memory. I didn't see a dynamic device loader in amongst the utilities, but there are a lot of them, and there are two at least of whose function I have no idea whatsoever (no - the documentation does not help). Again, the DMC utilities came to the rescue. I had trouble with the equivalent TSRCOM (TSR Control, simtel and mirrors) utility, and I rapidly gave up the experiment in favour of DMC's. Windows is a real bugbear. I finally determined that the following utilities may *not* be loaded high if windows is to run in enhanced mode over lastbyte: NNANSI.SYS, SETVER.EXE, KEYB.COM. At least one of these kiboshes lastbyte + windows if loaded low too (I have forgotten which!). I eventually used DMC's note utility to release all TSRs before windows ran, then put them back again afterwards, and this seems the best way forward. A simple win.bat copes easily. These remarks apply to windows running on top of qemm running on top of lastbyte. I have yet to get win/3 running on top of lastbyte alone (+ HIMEM.SYS and/or SMARTDRV.SYS). Company Stability ---------------- Key Software have been producing lastbyte since 1989 and started up in software production in 1983. They behave like a secure outfit (but I have no way of knowing ...). The docs list several other well known manufacturers of utilities as distributors. Company Support -------------- My email to Dan Lewis returned quicker than it had a right to. I didn't try anything else. Dan's letter was commendable for length and informativeness. I hope he does not waste his time that way always, but he insists that he enjoys the feedback he gets from such contacts. Documentation ------------- Reasonable. Certainly lengthy and detailed, but not really written from the user's point of view (a general failing of the utility). I wanted to know how I should set up my 386, and the best clue I got was from the install routine, documentation notwithstanding. Hardware requirements --------------------- effectively, 1x{286/386/486} with the appropriate chip set or 1x{8088/8086} plus hardware expanded memory but it is the shadow ram controller chip that is the real requirement. It happens that supported controllers are the norm on 386/486s, but many 286s and 8086s are documented as not needing EMS either, and their controllers will yield to lastbyte too (I cannot test this). Performance ---------- As it claims. I'll skip a long discussion of precisely what lastbyte does - surely everyone has tried umpteen memory managers by now? - but the salient points are: 1) lastbyte does not run in protected mode. So you *can* run windows (3.0, maybe 3.1) in enhanced mode over it. Not many memory managers which bring you shadow ram do that. I'm having some trouble making it work for me, though. So far I have always needed another memory manager loaded on top, but that is good enough, in principle. 2) As noted, it reclaims shadow ram for use as DOS UMBs, or bankswitch memory, or whatever else you can squeeze out of it. For me, that has the effect of freeing up the extended memory that my other manager was using to fill in as UMBs. So I gain as much extended memory as I had occupied UMBs (96K). 3) Lastbyte will use expanded memory to fill in as upper memory on a machine with expanded memory hardware (*3), and no physical upper memory itself. So it's a great way of rejuvenating 8086s. For non-386 machines with this hardware, I must recommend lastbyte _unreservedly_. As noted above, it is claimed that EMS is not a requirement here either, but I do not know what the results are like. --- *3 hardware to the standard of LIM 4.0 is certainly a requirement if you want more than 64K of UMBs, but more than the minimum 64K window must be physically supported too. Under 3.2, the expanded memory service will be disabled (and you get 64K of UMBs at most). The situation is complicated - but my machine is not playing in that particular ballpark. 4) It comes with many related utilities which can interface with the manager directly, such as a ramdisk, a DOSKEY replacement, an UMB dispenser, a device loader, a TSR loader, and more. For me, all these are something of a _minus_, as I don't want to be tied in to one manufacturer's products, and I have plenty of utilities that I want to go on using. All I really want to have is the UMB dispenser, which I can install in config.sys and then use to dole out UMBs to whatever requests them. I'm generally happy with what all the utilities do, and how they do it. I am just not happy with so _many_ of them in as an operational design. I could not see what business a utility-for-utilities supplier had with providing some of these (the keyboard history utility in particular). I would still rather they concentrated on making the memory manager support open systems, but I have had the technical reason explained to me now, and I can see the benefit! Still, I would have thought that a separate utility to load DOS buffers high was not entirely necessary, nor a utility to load DOS file control blocks, and this kind of clutter adds to the feeling that severe demands are being made on the installer's technical abilities. Very stressful. A dynamic device loader is not included, but other suppliers loaders seem compatible. Local support ------------ There seem to be official distributors in many areas of the world. But I don't suppose they're going to rush round. Email works. Support requirements ------------------- Beginners need not apply. You need to be fairly aware of what you are doing to install any memory manager, and a few (!!!) duff trials are part of the learning process. The more you know about 386 memory here, or expanded memory, the better (I am still learning about `bankswitch' memory). A good general PC memory tutorial comes in the documentation. General Remarks Why am I happier with lastbyte this time round? (1) They've provided a very useful feedback utility, HIGHMEM, in the style of qemm's MFT, which provides a scrollable view of how lastbyte has organised your memory. This may sound trivial, but, believe me, it is _essential_ to be able to get a good idea of how you're doing when playing around with memory. The lastbyte.sys manager itself also gives a useful sign-on display, including bandwidths and buswidths in the map (necessary to you for avoiding clashes with DMA-performing utilities - though I missed where the manual said so). (2) This is the first version of lastbyte which can reclaim my chip set's shadow memory for my use. This is something which QEMM, for example, can _not_ do for me -- it uses extended memory to fill in (other chip sets may be more fortunately treated). I should explain that I am looking for just one thing in a memory manager - the ability to reclaim shadow memory for my use. I have Mb's of extended memory which qemm and other managers do wonders with, but I only know of one other utility (umb_drvr) which will bring me shadow ram. There is 128Kb at least of usable memory up there, just shadowing my VGA and main bios, and I'd like it back. And, yes, lastbyte now seems able to do that job for me. But it's not quite the bottom line. At $29.95, that 120Kb comes in quite expensive in comparison with the cost of another megabyte of extended memory. And I can't map it the way I want it. Still, it's not so expensive that I can't afford to buy, but my decision won't be based on strict economics if I do. (In fact, I am paying for precisely as much of the reclaimed memory as I can figure out a use for, and at the moment I can think of something useful for only 96K of it - but half of the upper 384K is available to me, I know). I would probably have junked (the shareware version of) lastbyte by now, on the grounds that I could do without a demo taking up space on my disk - what else can I call something that gives me only 32Kb of UMBs and professes to disable the rest of the upper memory map? - if I had not made the discovery that one can load qemm and other memory managers _after_ lastbyte, and get that shareware 32Kb _plus_ whatever the other manager gives you. Allocating an extra 8Kb or so as bankswitch memory allows the lastbyte utilities to virtually disappear from UMBs too. Qemm sees lastbyte-managed space as an adapter. I guess the rest of upper memory isn't disabled after all, but the documentation did not let on that way! One should use the /REPLACE option of HIGHUMM.SYS and load it after the second manager. One more cavil before I wind up: the shareware version is limited to just two lastbyte utilities loaded at a time, so you can understand that I had a great deal of trouble trying them all. I used HIGHDRVR.SYS to load HIMEM.SYS high, and HIGHUMM.SYS to dispense UMBs. That left me no room to try any other lastbyte utilities, until I discovered that qemm could be loaded in afterwards (and instead of HIMEM.SYS), at which point I made some more progress. In particular, I really could make no headway with an expanded memory driver (EMM386.EXE) that I tried, since it isn't intelligent enough to load itself out of the way like qemm, and I lost much more memory than I gained. But I believe the two are compatible, and I would appreciate it if someone would tell me how to set lastbyte and emm386.exe up together in an optimal way. I got very fragmented upper memory out of my arrangement. But then I don't have hardware expanded memory, and lastbyte seems to expect that rather than a software emulation. My favoured shareware setup turned out to be extended memory, running a hyperdisk cache in lastbyte's UMB, with most of upper memory excluded from lastbyte. It seems that one _has_ to set DOS=UMB - a pity, because I loaded qemm on top for more UMBs, and qemm does a better management job. DOS=NOUMB blows away the UMB that lastbyte supplies. I couldn't get the lastbyte shareware 32K UMB to go anywhere but C000. In fact, setting D=C000:32 (which just says 32K at C000) in the lastbyte switches disabled lastbyte completely. Error messages are altogether incomprehensible, as one might expect, and I have no idea at all why most of my failed experiments failed. I cannot set D=F000:32, for example, as the documentation says I should, apparently because the shadow ram there is not read/write, but it has taken a week of experiment and correspondence to find that out! Under the registered version, the 32K restriction disappears, and I chose to let lastbyte have 96K of UMBs, and a few K of bankswitch memory. The UMBs were more than enough to load all my TSRs and devices in, and I could then run qemm on top with upper memory excluded, simply supplying extended/expanded memory. I have so far (after a weekend's trying) only managed to run windows in enhanced mode over lastbyte when qemm is loaded too, and with certain devices and TSRs removed from upper memory. Conclusion: lastbyte 2.02 ----------- I believe that lastbyte is just the thing for you if you have a non-386 with LIM 4.0 hardware expanded memory. For a 386, the shareware version is not convenient to use as it stands and should be regarded as a demo. The registered utility is very worthwhile technically, but still has a cumbersome interface, which, however, is marvelous by the standards of most memory managers. If it doesn't hurt you to buy, or you absolutely must have that shadow ram and you have the right chips, buy, by all means. It is cheap enough to make a mistake over ($29.95). Note that you can use the shareware version free to reclaim 32K of 386 shadow ram at the cost of some fragmentation of upper memory, if you already run a conventional memory manager. And it seems to be as compatible as a manager of this sort is possible to get with other utilities and devices. Needless to say, I am very impressed by any utility of this sort, since a lot of technical knowledge and programming effort has to go into it. But I am reviewing it from the user's standpoint, so my apologies for some relatively harsh words. If I knew how to do it myself, I wouldn't need to look at Key Software's fine utility! I am just disappointed that it isn't _better interfaced_. There isn't anything technically wrong at all, but setting it up takes a lot of work, and you may well waste more time over that than the space you save is worth to you. - PTB 1992