Conference pamsrc::objectbroker_development

A little bit more info. Using vc++ 4.2 and NT4, I can make the
LIBC warning go away by selecting:

	build
		settings
			link
				input
					ignore libraries

Type LIBC here and the LIBC warning goes away. That doesn't 
fix the _memmove problem though.

Using Task Manager on NT4 (when MSDEV jams up debugging OBB programs)
I see that MSDEV is taking up to 99% of the CPU. The only way out
is to kill it using TaskManager or PView.

A friend of mine looked at where the program was when it jams and
he thinks it's somewhere in CORBA::Environment.

I'm wondering if maybe between 4.0 and 4.2, Microsoft has changed
the default libraries which are included (perhaps it now defaults
to multi-thread as Sepp hypothsizes).

In any case, it's a big pain.

John D.

    To Thread or not to thread; this is the question to be answered by
    Microsoft. If MS VC++ 4.2's application wizzard creates by default a
    code model which calls for multithreaded libraries for every MFC/OLE
    application, then that seams to be OK for MFC/OLE applications.
    
    Otherwhise this does not mean that any other code has jame MSDEV.
    
    So what does our OBB code add on nasty behaviour, leave off, not
    marking correctly, to make MSDEV jam and hung when mixed into MFC/OLE
    code fragments? 
    
    Can we mark, make known somehow our OBB code to tell the remaining
    stuff, VC++ OTS, libs etc. that this section is not thread safe ? 
    
    Marking that this code is not organized to run in a thread. Or to flag
    it clearly as: to belongign to a clear identified only-one thread. 
    
    When I debugged the launch of my application, I can see lots of thread
    dealings and thread setups taking place on the just to be launched
    application. I think this IS the default model used for MFC/OLE Apps as
    generated today by the app's wizzard and then supported by MFC/OLE VC++
    LIBS.
    
    MS to confirm this.
    
    Sepp,

    
>    Can we mark, make known somehow our OBB code to tell the remaining
>    stuff, VC++ OTS, libs etc. that this section is not thread safe ? 


I think that this is actually a general question that needs to be
answered by Microsoft. How do you get an application built with VC++
4.0 to be able to be mixed with VC++ V4.1 or V4.2 applications and run
in the debugger. I do not think that this problem should be specific 
to ObjectBroker applications. Other applications built with VC++ 4.0 
will probably have the same problem.

I checked the internal VC++ for AXP notes conferenc and found
that other individuals were reporting similar problems with 
applications that didn't use ObjectBroker, but were using VC++ 4.2


Paul Patrick

Did anyone try making their app single-threaded? Does that
stop it hanging? Remeber, the non-debug images run fine.
(I'm fed up of putting AfxMessageBox everywhere!).

(Cant try it here - this customer has v4.0).

John D.

A swedish customer has bought OBB V2.7 for WNT. I was 
giving a training there two weeks ago using V2.7-11 
and I have found additional information:

(1) Using the debugger with C bindings works well.

(2) Using the debugger with C++ bindings works well as 
    long as you don't see the call to the stubs in the
    active window. If the stub is encapsulated into a
    user defined C++ class, stepping over the method 
    invokation of the new class does not cause any 
    problem.

Do you have any news ?

Cheers.

Frederic

>Do you have any news ?

I'm not sure what news you are looking for. ObjectBroker does not
support VC++ V4.2. This is a subscription version of VC++ and I do not
think that we will ever support that specific version. Especially
given the problems there seem to be with using it for all customers,
not just ObjectBroker ones. In the ObjectBroker Bryce release in the
fall/winter 1997 we will consider new versions of layered products
such as compliers. Our supported compiler list will generally be ones
that are widely available as non-subscription products. We have not 
selected the supported compilers for ObjectBroker Bryce, as we are too 
far from the SSB release, and want to consider what other companies 
have on the market when we are closer to a ship date.

We're not asking for support on this. We understand it's
not possible to support everything. What we want is to
support customers. Some of them (*all* the customers I've
seen in the last few months) use v4.2. 

We're not asking you to engineer round a Microsoft problem
we're asking to share experiences and possible workarounds.

For example, I tried to build using "debug single-thread" -
this did not help. *Perhaps* the OBB CXX libraries have been
built using the default "multi-thread" option.

Nobody need reply to this thread if they haven't got something
positive to bring to this problem.

John D.

John,

per MS recommendation, our libraries are built using the multi-threaded, 
DLL version of the C run-time libraries and our C++ libraries contain
objects that are compiled for use with the same multi-threaded DLL
version of the library.

According to the information I've seen, this means that an application
using a library built the way ObjectBroker is built, should like against
the same multi-threaded DLL version of the library.

This has no direct baring on whether ObjectBroker utilizes threads 
or is thread-safe.


Paul Patrick

Re: .-1, Paul

Ok, thanks for the info. I'm just trying to 
get round this problem of the debugger jamming.

Its an interesting data point that the C-bindings
dont jam.

John D.

    Our customers once familar and strategically commited to use MS Visual
    C++ (and other development tools) will get new versions of this tools,
    supporting new features such as going from OCX to activeX to Java and
    they want more benefit from xyzWizzards, also from AddIns to IDE.
    
    Customers ....
    
    will definitly not switch compilers or development environments what
    ever vendor delivers it just because someone in Digital or Microsoft
    can't come up with a fix to a problem. Wheter Digital fixes the problem
    with a CLD releas of OBB or Microsoft fixes it with VC++ 4.3abc is of
    absolute no interesst to customers. Thats the market. Customers
    understand that it takes a bit time to have ObjectBroker supported by
    VC++ 4.2. 
    
    THe facts however show clearly that we get hungs as soon as we call
    into OBB stubs ... it's easy for MS to say, just fix it Digital, as
    long as you cant prove our violation, when MS will fix it within a
    given time frame. (maybe next version)
    
    Customers will not excuse a problem but drop a product if time to fix
    the problem is over in their own mind. Thats the market.
    
    Sepp 

Surprisingly, I agree! ;-)

In this particular case, vc++ 4.2 is the first to
come complete with STL. The project which is 
currently taking a lot of my time values STL a lot
and have no intention of messing about with earlier
versions just to suit ObjectBroker.

We are now working on NT because DEC C++ on Alpha VMS
couldn't compile STL (it takes *many* hours and then
sometimes gets errors in generated code). So, we
dropped Alpha boxes in favour of Intel, VMS in favour
of NT. I don't suppose the customer is a *long*
way from saying, mmm now we're on NT, I wonder if 
Orbix blocks in the debugger?

If anyone has any useful input I'm interested.

John D.

    Have you tried building your project with the C7 compatible
    debug option under the C++ setting ?
    
    

No, we haven't tried that. I'm away from the project for a
couple of weeks. Then back for final acceptance of this phase.
Things are going well, despite the lack of debugging.

I'll suggest they try .-1.

John D. 

    Hi there,
    
    I met the same problem today with Orbix and VC++ 4.2 on NT 4.0.
    It occurs whenever I ask the debugger to display the contents of
    a variable whose datatype is CORBA::Environment. This looks like
    something that was reported in .10
    It would also explain why the C mapping does not raise this problem.
    
    I will try with VC++ 5.0 later (a new adventure in sight ;-))
    
    Stephane.

Re: .25, Peter
    
Great! That seems to solve the problem for me on W95/VC++4.2/OBB2.7-11
I cant try it on NT4 here. (Jacques or Gunnar can you try it?).

Thanks for the info, that's been a long-running pain.    

John D.

For those who want to try this:

	VC++
	  Build
	    Settings...
	      C/C++
	        General
		  Debug info:
		    C7 Compatible

Here's what C7 seems to mean:

C7 Compatible   Produces an .OBJ file and an .EXE file containing line numbers
and full symbolic debugging information for use with the debugger. The symbolic
information includes the names and types of variables, as well as functions and
line numbers. Command-line equivalent: /Z7
  
This option generates complete debugging information and places all of it in the
object file. It is recommended that for greater linking speed and efficiency you
use /Zi instead of /Z7. Use /Z7 only if you need the debugging information
placed entirely in object files, such as when you want to distribute a
debuggable library. If you use precompiled headers (PCH), you can combine /Yc
with /Z7 to eliminate duplicate type information. This method creates a
significantly smaller library because type information is in only one object
file. However, to link with other objects in the library, either your program or
the other objects must reference a public symbol in the object that contains the
type information in order to link the PCH type information.