• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Master Volume widget

Started by adamr, 2007.09.09, 22:06:14

Previous topic - Next topic

adamr

Has anyone else tried the new Master Volume xcenter widget? I followed the readme
instructions for the plugin dll but xcenter refuses to load the dll. The log shows
this:

2007-09-09 17:20:10:73 T011 plgLoadClasses (D:\cvs\xwp100\src\shared\plugins.c, line 352):
    Unable to load plugin DLL "C:\TOOLS\WPS\XWORKPLACE\plugins\xcenter\jvolume.dll".
    DosLoadModule returned code 2 and string: "CPPOM30"


I am using OS/2 Warp 4.5 with XWorkplace 1.0.7.

Adam

RobertM

Hi ADam,

I have yet to try the new xCenter Plugin in question, but it looks to me like there is a DLL missing (or not in the right place). I'd suggest re-reading the instructions and see if the Plugin requires anything else to be installed or says that certain things need to be in either (a) your libpath statement, or (b) one of the xWorkPlace folders...

If I get a chance to try it out, I will see what I come up with and let you know.

-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


adamr

From the readme file:

Requirements:
XCenter

Useage:
Close XCenter if it is running.

Place jvolume.dll in the XCenter plugins directory.

Start XCenter
.

According to the readme, this is all that needs to be done.
I followed these instruction exactly The dll refuese to load.

Adam

RobertM

Hmmm... something is missing then - or the DLL was compiled with a dependency for a VAC++ DLL instead of compiled with all the needed dependencies in the one DLL.

CPPOM30(.DLL) is a VisualAge C++ (v3.0?) DLL - and the error *seems* to indicate it is trying to load the DLL and failing...

That DLL should not be on your system by default, and would have to come with an application of some sort that required it. You may want to check to see if a copy is on your system - and if so, move it to your OS2\DLL directory and try again...

A simple way to find it would be from a command window do a DIR CPPOM30* /s /p for each and any drive you have... I'd start with checking whatever folder the xCenter Plugin was originally decompressed to...

It could honestly be that a DLL is just simply missing from the package... an easy mistake (for a programmer) to make. (The programmer would) test the plugin, forget that there are other dependencies, because the DLLs depended on are already installed in their libpath.

-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

#4
I do have a copy of the DLL in question (it's a required DLL for Lotus Domino GoWebserver v4.6.2.8 and lower I believe) - if you have Warp Server for eBusiness, you will have the DLL once you install LDGW (and it will also automatically update your path statement).

If you don't have the DLL, I can send it to you or make it available from my Web Server... I cant test the volume DLL since I have the CPPOM30 DLL already installed and thus wont be able to reproduce your error...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

#5
Well, with that DLL in place, the plugin works fine, so I think that is the issue...

...And, according to the xCenter DLL, the VAC++ DLL is definitely a needed dependency... Perhaps someone needs to contact the author and ask him about resolving it (either a package that includes the needed DLL, or a recompile that doesnt have the dependency...


-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


davidfor

CPPOM30.DLL is a VisualAge C++ runtime DLL.  This should not be on anyone's machine unless they have a copy of VisualAge C++.  But, copies of it with different names might be on the machine.

What is happening is that when someone develops code with VisualAge, they will probably need to link to some runtime libraries for the code to run.  This can be done either at statically at build time, or dynamically runtime.  If it is linked statically, it makes the executable bigger but easier to install (in this case, only one file).  If it is dynamically linked, the executable will be a lot smaller, but will need to use a DLL with the runtime code in it.  In this case, it is dynamically linked and the runtime DLL is not included with the executable.  I fell over this problem years ago when I released my SetiView/2 program.

But, there is a problem.  The VA C++ license says you can redistribute the runtime DLLs but they must be renamed.  This is done with a program called DLLRNAME.  This renames the DLL and the references in the executable to point the the new name.  As there is probably a few versions of this DLL on most machines with different names, it is possible to bind to one that is there.  My suggestion for the developer would be to see if there is one in the XWorkplace directory and use that.  I don't have access to an OS/2 machine at the moment (I'm at work) so I can't look.  If there isn't one there, the need to decide how to link the library in and recreate the package.

adamr

Yes, that was the issue. I placed a copy of the runtime library in a libpath directory and restarted xcenter.
Problem solved.

thanks,
Adam