Conference pamsrc::objectbroker_development

2469.0. "VC++ 4.2 Development Environment issue?" by SNOFS1::RASMUSSEN () Thu Apr 17 1997 01:09

I have read notes 2369 and 2414. 2414.19 from RECV::SLAVIN states that
ObjectBroker does not support VC++ V4.2. 

1) Is this the official position?

2) To what level of interest is ObjectBroker development interested in
reporting (possible) problems under VC++ 4.2?

Just like some of the other entries, my customer is also reluctant to be
forced back to version 4.0 or 4.1 of VC++ 4.2

Whether the official line is supported or not, I would appriciate some
feedback on the following problem.

OBB  V2.7-11 was installed on a node running OpenVMS V6.2.
The same version of OBB was installed on an Intel NT 4.0 PC on which Microsoft 
Visual C++ V4.2 has been installed.

Problem Description:

The attached T.IDL was used to generate the skeleton files using QuickStart 
under VMS.

[[ T.IDL : 3880 in T.IDL ]]

The Server program was compiled and started under VMS.

On their PC, a Visual C++ project was created which includes the following 
files:

     . the generated TCLIENT.C
     . the generated TSTUB.C
     . the OBBQUICK.C that comes with OBB


Project settings, included:

      Include File Directory,
      Link library,
      Preprocessor Definitions

 were updated accordingly to enable program to compile.

When the linked TCLIENT.EXE is run outside the Visual C++ development 
environment, it behaves as expected and was able to interact with the 
TSERVER program properly.

However, when the program is run within the C++ Development environment, the 
program keeps failing with the following errors:

 -------------------------------------------------------------------

CORBA_ORB_string_to_object failed

System_exception encountered: <null>
OBB_MSGFAIL <f>, Could not format error message: 048BA07A <hex>

048BA07A,
048B9132,FILENAME,OBB_User.co,

 -OBB_MSGFAIL <f>, Could not format error message: 048B9132 <hex>
FILENAME, OBB_User.co,
048BA07A,
048B9132,FILENAME,OBB_User.co,

 -------------------------------------------------------------------
The same problem occurred with both the Debug and Release version of the 
image.

Please advise if OBB functions in general, or just 
CORBA_ORB_string_to_object in particular, may not work in the C++ V4.2 
development environment.

Or can you please advise if there is anything else that the customer can do to 
get around the problem.

As they need to develop and release a new OBB 2.7 program developed in C++ in 
the near future, an early reply would be much appreciated.

Note: customer has encountered problem (confirmed by Microsoft as bug) with 
VC++  when the Language setting of my PC is not English (US). They currently
have it set at English (US) and still observing the problem.
==============================================================================
T.IDL
module PCMSS
{

  // Some constants used (Note that putting them here eliminates the need for
  // a separate user-written header file to share this information between
  // client and server sources)

  const long	DATESTRLEN	= 11;	/* dd-mmm-yyyy */
  const long	TIMESTRLEN	= 8;	/* hh:mm:ss */


  // An enumerated list of application-specific errors, accompanied by
  // explanatory text strings.
  enum ERR_TYPES 	{
			 ErrGetDate			// Can't get Date
			,ErrGetTime			// Can't get Time
			};

  // Define the complex data types common to the interfaces
  // in this module.

  // We define one user (ie, application-specific) exception structure. All
  // MSS user exceptions return an enumerated value that indicates the
  // specific reason for the exception.
  exception UserExcep 
  {
	ERR_TYPES 	Reason;
  };

  // The Message Switch Interface

  interface MsgSwitch {

	void GetVMSTime ( out string TimeStr )	// In format: hh:mm:ss
          raises   (UserExcep);

	void GetVMSDate ( out string DateStr )	// In format: dd-mmm-yyyy
          raises   (UserExcep);

   };  // end of interface MsgSwitch

};  //end of module PCMSS

    Also keep in mind that Microsoft Visual C++ Version 5.0 has hit the
    field yet (not just the Beta) the real Version 5 is available.
    
    Could that mean that ObjectBroker engineering is bypassing Version
    4.2 support and goes straigth to Version 5.0 ?
    
    Sepp,

    RE: .0
    
    The customer has tried VC++ V4.0 to see if it works according to Hoyle!
    
    It does! They have now asked for a formal statement on the support of
    VC++ V4.2 (and no doubt V5.0 will also come up at some time) ie. will
    ObjectBroker Engineering accept calls on VC++ 4.2 (& 5.0) and resolve
    or escalate to Microsoft as appropriate? 
    
    Regards
    
    Wayne

    
>    The customer has tried VC++ V4.0 to see if it works according to Hoyle!
>    
>    It does! They have now asked for a formal statement on the support of
>    VC++ V4.2 (and no doubt V5.0 will also come up at some time) ie. will
>    ObjectBroker Engineering accept calls on VC++ 4.2 (& 5.0) and resolve
>    or escalate to Microsoft as appropriate? 

ObjectBroker lists the specific compilers that it supports in the
Digital SPDs, and now in the BEA product information. We are
interested in hearing customer experiences when using other
configurations, compilers or layered product. However, we can only
support the specified configurtaions listed in our documents. Future
OBB versions will consider new operating system versions, new compiler
versions and other new layered product versions. 

This means that VC++ V4.2 and VC++ 5.0 are not supported by any
current OBB products. 

> Could that mean that ObjectBroker engineering is bypassing Version
> 4.2 support and goes straigth to Version 5.0 ?

	FWIW, from my understanding VC++ 4.2 is not a generally available
	version, but is only available via subscription.

	also from what I've heard, VC++ 4.2 is very buggy and/or
	has broken lots of things (ie. not very backwards compatible).
	so supporting VC 4.2 would be like trying to support a beta
	version of NT, imho of course.

We are developing a large application using VC++ v4.2 and
OBB v2.7-11, the C++ bindings.

We have pretty well finished this phase of the project
successfully (a few weeks left). 

We haven't really had too many problems which relate directly
to v4.2. I would say the worst is not being able to debug.
(But by now we rarely need to as the application is well made! ;-) )

We've had a number of problems related to OBB: version differences;
generated code (wrong, or weird); memory leaks. But we've 
got round all of them fairly easily. So, if you want to 
use v4.2, I'd say do it.

A really nice extra is built-in support for STL.

John D.