Object Desktop - Cons- by Edward Crouser

The Problems with Object Desktop

Object Desktop adds a new level of functionality to the OS/2 Workplace Shell. However, along with these enhancements come several performance hits which users should be aware of before they purchase the product. The end user should carefully look over what they expect from it and how it will perform on their system. I installed Object Desktop on several different systems for this review, a 486DLC-25, a 486DX-66 (both with 8 meg of RAM) and a Pentium with 16 meg of RAM.

Lockups

Every system that I installed Object Desktop on started to experience lockups that didn't happen before the instal. Stardock claimed that much of these problems were due to a bug with running DOS or WinOS2 sessions. Since many lockups occurred when I was using only OS/2 software, I was a little wary of this explanation. Still, Stardock promised a fix and quickly delivered upon it. The fix, which by the time you read this should have made its way into the manufacturing line, quickly solved all of the lockup problems that I experienced. Since installing the fix on the different machines, I haven't experience any lockups with any mixture of applications that I've thrown at it. You can download the fix from Stardock's homepage or through their new FTP site. Speaking with other Object Desktop users, they reported to me that they still experience some lockups when trying to access certain network drives. It is important to note that I have not been able to duplicate this problem.

Performance

Stardock Systems recommends at least a 486DX-33 with 8 meg of RAM for using Object Desktop. Through my trials however, I found that the cpu speed has little to do with the overall performance, with memory being the main constraining factor. I first installed Object Desktop on the 486DLC-25 with all options installed. When it first came up, I was very impressed with all of the features that are included. However, I was disappointed by the amount of swapping that took place. It seemed that whatever I did, loading a program, or simple file management took an enormous toll on the system. Using the IBM Internet Access Kit became practically unbearable, due to the constant swapping.

Several Object Desktop users were quick to point out that this was probably due to the Control Center, which seemed to eat cpu cycles because of the constant updating of the cpu meter and system clock. Stardock was nice enough to include a setting for the Control Center that allows you to set the priority level of the screen painting. However, setting the priority to low had no effect on the swapping on the 8 meg systems.

So I disabled the cpu meter, system clock and virtual desktops. This did help somewhat, but I still experienced too much swapping. Whenever I clicked any folder on the Control Center, to bring up a list of the objects within it (much like the Windows 95 task bar) it still swapped and was too slow for my use. I then decided to not use the Control Center; even though I love the functionality, on the 8 meg systems it did not seem to be usable, no matter what the cpu speed or features I disabled.

The Tab Launchpad also seemed rather slow on bootup on the 486DLC-25 and the Launchpad that comes with OS/2 Warp, was much faster. This, however, changed from system to system, as the cpu speed did seem to have a lot to do with it.

The Object Browser also seemed to run too slowly at high resolutions on the 8 meg machines, but this changed as I took the resolution down to 640x480. It was still somewhat slow, but usable if you feel that it increases your productivity. I have never been a big a fan of file maintenance through a GUI; I prefer to stick with the good old OS/2 command line. This will vary according to your taste.

The story of performance, however, differs on the Pentium with 16 meg of RAM. Object Desktop's swapping was nowhere near as bad as on the 8 meg machines and the added user productivity enhancements made it the perfect companion to this type of machine. When I applied the fix to the Pentium machine, all problems were solved in terms of lockups, so there was no reason I couldn't keep it on the machine full time with all of the features enabled.

Uninstall Routine

Once I came to the realization that I wasn't going to be able to run the full featured Object Desktop on my main machine with only 8 meg of RAM, I decided to uninstall some of the components. I loaded the "Installation Program" from the Object Desktop folder on my desktop and proceeded to click on every module that I wanted to uninstall and then clicked "uninstall". It seemed the logical thing to do. To my surprise, it uninstalled every single component of Object Desktop, taking with it things that I wanted to keep and didn't select from the installation menu. So, I headed straight to the manual. Page 2-2 reads, "You may choose to use a manual uninstall procedure if you find that the automated uninstall doesn't work, or if you want more control over your system."

At this point I decided simply to reinstall with only certain items: folder enhancements, Task Manager, archive templates, and the WPS replacement classes. This second installation caused the install program to crash. I then shutdown my computer and rebooted and to my surprise it had seemed to install fine. The problem stemmed from the README.TXT file on the disk, since that is where the install crashed, I haven't had a chance to trace the problem and find out exactly what was causing it.

Things I'd Like to See

In moving from Windows to OS/2, the first thing that some users miss is the loss of the ALT-TAB key. The Task Manager fixes this problem as it allows the ALT-TAB key to be used on the OS/2 desktop with the same functionality as the Windows counterpart. The only thing that was missed however was full screen DOS and OS/2 sessions. If you are working in a full screen DOS or OS/2 sessions you cannot ALT-TAB switch out to another task, which is a drawback and something I hope that can be implemented in a future release. The Folder HyperCache also didn't work the way I expected. I had expect some type of memory cache to simply speed up the access to all folders, but what I found was that you must enable it across every folder you wish to be cached. Not only this, but all the HyperCache seems to do is open the folder and hide it in the background, thus allowing quick access to it, but also eating up memory by having the entire folder opened at all times. I also wish that it would have placed an object on the desktop for the Stardock Editor so that you may have quick access to jot down notes. I know that there is a way to do it, but I feel that Stardock should have put it in the install.

Conclusion

Object Desktop packs a lot of punch in terms of usability updates to the OS/2 Workplace Shell. But, there are certain trade-offs when running in low memory situations. If you have 16 meg of RAM, Object Desktop is worth every penny. But if you only have 8 meg of RAM, you need to evaluate exactly what it is about Object Desktop that you can't live without and be sure that you are able to work with it under usable conditions. Even past this though, I found Object Desktop to be indispensible for any of the machines that I tried it on, whether or not I was able to use the full features of the program on each of them. Hopefully Stardock will release a less memory hungry program with more speed, so that those of us who only have 8 meg of RAM may use everything, including the Control Center.
Object Desktop v1.0
SRP: $89.95

Stardock Systems
13405 Addison
Gibraltar MI, 48173
Voice: (313) 453-0328

BBS: (313) 453-1845
CompuServe: GO STARDOCK
Internet: stardock95@aol.com
IBMLink: Stardock CFORUM

Edward Crouser is a shareware author and contract programmer who specializes in OS/2 related material. He is a member of Team OS/2 and has been using OS/2 since the 2.0 beta.

Send a letter to the editor.

Contents | Previous Article | Next Article

This page is maintained by Haligonian Media. We welcome your suggestions.

Copyright © 1995 - Haligonian Media