Novell Home

Shared Code and the 16-bit Client

Novell Cool Solutions: Tip
By Meg Desposorio

Digg This - Slashdot This

Posted: 3 Jun 1999
 

You know how when two people get divorced, sometimes he gets the tv and she gets the remote; she gets the sofa, he gets the cushions; he gets the comforter, she gets the duvet? It's kind of a bummer because all the stuff they once shared doesn't work so great once it's been neatly divided into two separate piles. Unfortunately, companies in our society aren't immune from divorce either...and it's even messier, if possible, then when people do it.

So if you're wondering why things aren't working so smoothly with your shared code and you feel like someone hauled off with the tv and left you stranded with only the remote, we're here to help you patch things up again. Just because GroupWise and WordPerfect went their separate ways doesn't mean you have to suffer.

Peter N. V. wrote: For the 16-bit client, there is an inability to specify where shared code goes during installation. Very important when running WordPerfect products. And no documentation for what to do about it! I can't get over this.

To which we responded: Good news, you can still specify shared code during installation. Click Custom Install, then click Destinations.

To which Peter responded: Thanks for the reply. However, your advice about shared code is fine for local hard drive installations, but what about when running the client from the server, which is what almost all of my clients do? How is the shared code problem resolved when running GroupWise as well as WordPerfect/Corel applications from the server which both need shared code? GroupWise does not let you specify where the shared code goes during installation of the \SOFTWARE directory and not a word about how to reconcile this with other WP apps using shared code already on the server in the documentation.

First of all, here's some general information about shared code for the benefit of you, Peter, and all our 16-bit readers. Shared code is a group of files that are shared among a number of applications, originally all produced by WordPerfect Corporation, and now produced by both Corel Corporation and Novell. Shared code has had two major versions: 1.x and 2.x. 2.x, for example, is used with GroupWise 4.1 or later and WordPerfect 6.0 or later. You can't install 1.x shared code and 2.x shared code into the same directory; however, you can (and it is our recommendation that you do) install all 2.x shared code to the same directory. Why? Because it'll work better. And because GroupWise shared code doesn't include some files that WordPerfect needs, and vice versa, as you've discovered in a most painful way, Peter.

New applications cannot use older shared code (without major glitches like things not working properly), so for example, if you have WordPerfect 6.1 installed, GroupWise 5.1 cannot use WordPerfect's shared code. But WordPerfect 6.1 can use GroupWise 5.1's shared code (installed over its own, with newer dated files replacing older ones). So, the way to ?manage? running GroupWise and WordPerfect or other shared applications from the server is to have them all use the same directory.

Peter, you are absolutely correct that when you first set up your software distribution directory by running INSTALL.EXE, you can't specify where shared code goes for GroupWise 5.x 16-bit, and we have passed that on as an enhancement request to development. However, after you set that directory up, you can run the 16-bit client SETUP.EXE to install shared code to the server directory you want. Click Custom Install, Files, Mark All, OK. (Mark All is important because different shared files come out of different parts of the installation, even the ones that aren't marked by default.) Next click Destinations, type the server location in the WPC Shared Files text box, then click OK and start the installation. All the shared code files will be installed to that directory.

A workstation user can then specify where shared code is by using a /WPC switch on the GroupWise command line, for example /WPC-F:\WINAPPS\WINSHARE. You can also specify the /WPC switch using a DOS SET environment variable or in the GroupWise *.ENV file. Now some tips on making the /WPC switch work for you: any switch on the command line will override what has been set in the environment variable or ENV file. And, if another shared code application which uses the same major version of shared code is already running before you start GroupWise, it does not matter where you specify /WPC; that session of shared code is already in memory, and even a command line switch cannot override it. The bottom line is, make sure that all of your shared code applications know where to get the right (and most current) shared code.

And Peter, you're not alone in the quest for the perfect shared code setup. Read on:

Daniel B., Sarasota, Florida, USA wrote: I have installed GroupWise for my bank's e-mail, scheduling, et al system. We are a WordPerfect shop (there are some of us out there that won't buy into the MS hype!). On Windows 95 installs of the 32-bit client, the integration with WordPerfect is flawless.

Here's the problem: I still have a number of Windows 3.11 machines running WordPerfect 6.1. These machines use server/workstation installs. When I install the GroupWise 6.1 client, I can no longer print! I've tried uninstalling, re-installing (both programs), deleting, reg-editing, the works! I have not gotten a consistent fix. Any suggestions? In my little brain, I have to believe it has something to do with the WPC20 directory that the GW install creates. Even after the uninstall of GW, WordPerfect will still not print. Error message is ?Cannot start WP Print Process.? Help me Please! The natives are very restless!

Hi Daniel. Let's hope the natives haven't sacrificed you yet?tell them to put down their weapons and let you read this answer. The printing problem you're experiencing is caused by shared code for these two applications being installed to two different locations. If GroupWise shared code is running (due to any part of GroupWise being open, including Notify), before any part of WordPerfect 6.1 (or PerfectOffice) is open, WordPerfect will use GroupWise's shared code and will point all of its shared processes to the GroupWise shared code directory. Printing is one of these shared processes. When you attempt to print, WPRINT20.EXE is nowhere to be found, because it's a file that is not included in GroupWise shared code, and hence is not in the GroupWise shared code directory. We know, it's confusing as heck.

Additionally, the preferred path for shared code in the Registration Database (REG.DAT) has probably been modified by GroupWise to point to its own shared code directory. So, the solution is to 1) Do a custom install of WordPerfect (or PerfectOffice or whatever shared application is oldest?note it has to use a 2.x version of shared code; see our answer to Peter above) and install the Perfect Fit components (this is another name for shared code) only to the C:\OFFICE\SHARED\WPC20 directory (or wherever you want to install shared code). 2) Do a custom install of GroupWise (click Files, Mark All) and specify that the shared code go to the same directory (click Destinations, type a path in the WPC Shared Files text box).

A quick fix is to move the necessary files for printing to the GroupWise shared code directory. First, make sure both applications are looking in that directory. In Program Manager, click File, Run, then type REGEDIT/V. Once the Registration Database is open, click Search, Find Key, type SHWIN2x, then click Find Next. Under the SHWIN2x key, edit the PREFERRED and WPWIN61 paths so that they match the OFWIN41 path (if they don't already). OFWIN41 means GroupWise, by the way?remember when it was called WordPerfect Office? To edit a path, click the path, then type a new path in the Value text box at the top of the window. Save the changes you have just made, and close the Registration Database. Now copy WPRINT20.EXE and WPPT20US.DLL from the WPWIN61 shared code directory (probably C:\OFFICE\SHARED\WPC20) to the GroupWise shared code directory.

Dallas I. wrote: Our company has recently installed GroupWise 5.1 All end-users are using the client installation. The Windows95 version has access to a spell checker while the Win3.11 version does not. Do you know what would cause this? Is this caused by not having proper rights to the GroupWise directories? All users of Win3.11 have the same problem.

Dallas, are your end-users using WordPerfect too? If so, the problem might be that there are two shared code directories installed: a WordPerfect one and a GroupWise one. You can reinstall WordPerfect (or whichever is the older shared application) and then GroupWise, making sure to specify that GroupWise install shared code to the existing (WordPerfect) shared code directory. Read about this in our answers to Peter and Daniel above.

Or, you can try the following fix: First, if your end-users have WordPerfect, copy WPSP20WP.DLL, WPUS.LEX, and WPUS.THS from the WordPerfect (old) shared code directory to the GroupWise (new) shared code directory. Next, open the C:\WINDOWS\WTAPI.INI file (in Notepad). The WTAPI.INI file tells the shared application, ?Pssst....here's where the Writing Tools like Spell Checker and Thesaurus are.? Edit the following lines:\

[WPSpeller]
PathExe=<new shared code directory>\SPWIN20.EXE
BitmapPath=<new shared code directory>\SPELLER.BMP
HelpFilePath=<new shared code directory>\WPSH20US.HLP

[WPThesaurus]
PathExe=<new shared code directory>\THWIN20.EXE
BitmapPath=<new shared code directory>\THESR.BMP
HelpFilePath=<new shared code directory>\WPSH20US.HLP

In each line, the ?new shared code directory? should be the GroupWise shared code directory. Finally, search the Registration Database (see how to do this in the answer to Daniel above) for SHWin2x and edit the paths so that they point to the GroupWise (new) shared code directory.

Now, if your Win3.11 users have workstation installs, the answer has a few more twists. Workstation installs read the WTAPI.INI file from the network, not from C:\WINDOWS (but if there is a WTAPI.INI file in C:\WINDOWS, still make sure the paths are correct). In the software distribution directory, create a WPCNET directory (for example, K:\SOFTWARE\CLIENT\WIN16\WPCNET). If one already exists, check to see if the WTAPI.INI file is in it. If not, you can create one by running SETUP.EXE and installing GroupWise files to a temporary directory, then modifying the WPTAPI.INI file that is created in C:\WINDOWS. Make sure WTAPI.INI is in the WPCNET directory. Then edit the six Spell Checker and Thesaurus paths to show the GroupWise shared code directory as described above. Next, create an OF_OF_.ENV file (use Notepad) in the WIN16 directory and include the line: /NI-<drive and path> (for example, /NI-K:\SOFTWARE\CLIENT\WIN16\WPCNET\). The /NI switch lets the GroupWise installation know where WTAPI.INI is. Now, check the WIN.INI file on each workstation to see if it has a section called [Writing Tools], and edit the WTAPIPath line if it is incorrect. The path should list the directory but not the file. Then, on the workstation, run SETUP.EXE from the \WIN16 directory. Also, make sure the user has read rights to the WPCNET directory.

Michael J. wrote: I work for a large networking company in South Africa and am based in Johannesburg. I am installing GroupWise 5.1 at a client site. They are using a combination of 32- and 16-bit clients. My problem is with the shared code for the 16-bit clients. I am being presented with various shared code errors. There are no other ?shared code? applications on the desktop (e.g. WordPerfect). Do I need to create a SH_SH_.ENV file?

Hi Michael. The SH_SH_.ENV file, located in the shared code directory, is an environment file. Any switches placed in this file affect any shared application that is using that shared code directory. So, if there are no other shared applications using the GroupWise shared code directory, then you shouldn't need this file. Now, since ?various shared code errors? can mean just about anything, it's hard for us to know exactly what is going on, but one possibility is that there used to be shared code applications, and while they may have been mostly uninstalled, some older shared code files may be lingering. If there are no other apparent shared code directories on the network or on any hard drives, then the files could have been installed anywhere (meaning, not in a shared code directory). You could try using a /WPC switch on the GroupWise command line to force it to look at the correct shared code. You can also try some of the tips for editing pathnames in the Registration Database in the answer to Daniel above. And finally, you can reinstall with a custom install, click Files, then click Mark All before starting the install. If that doesn't work, we recommend you contact Novell Technical Services for more in-depth troubleshooting.

Phew! We hope this article covered everything you ever wanted to know about shared code...and maybe even a little bit more.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell