>I was not referencing her article, however, I was referencing some Power Point presentations
>which I've kept around, and Lord knows if I'm allowed to share them (probably not). In them, I
> can see VC++ code WITH ATTRIBUTES, and this was in the VC6 days. Note that this version
> of the language NEVER SHIPPED, and primary development was moved over to Cool. The
Well, without knowing exactly what you are referring to I cannot argue with you. Mary's article did have C++ with attributes, isn't that what you are talking about?
I attended several C++ meetings at Microsoft in the timeframe you are talking about, and I did see some attributed C++, but I cannot remember the details (I've got my notes somewhere...). Of course, one of the aims of the VC team at that time was to produce attributed unmanaged C++, which did appear in VC7. And, of course, Managed C++ in VC7 is attributed. So when you say that an attributed version of C++ never shipped, well, several versions have shipped, but perhaps not the one that you saw in your powerpoints
> attributes in the sample code were mainly MTS-centric, which makes sense given the MSFT
> mindset at the time -- make developers more productive in a COM+MTS-activation world.
Don Box produced some 'attributed' C++ where the attributes were XML. Again, that was in the time frame you mention.
> Looking back further still, the original COM+
> was more like COM+ 2.0 (with attributed-based
> programming extensions to C++, no less), but
> that got scaled back and the shipping version
> of COM+ was more akin to COM+MTS.
Are you referring to Mary Kirtland's MSJ Dec 97 aricle? That was.NET, not COM+ component services. Yes, the article title said COM+ but her article was about the client side runtime, which is what we now call.NET. What we now call COM+ is the server side runtime, and Mary's article was not about that.
Both MTS and COM+ 1.0 (and 1.5 in XP) use the catalog to contain information about configured objects. Unmanaged C++ did not have attributes (VC7 does but that's a code generation tool). Instead you had to apply configuration through the COM+ component services explorer, or write some convoluted OLE automation code. The reason why you have to write convoluted OLE automation code is that MTS and COM+ were (IMO) provided to fix the problems that VB6 had with COM. That is:
1) It's pointless calling CoInitializeSecurity in VB
2) VB can only produce STA objects so has poor scaleability
Further, Win32 security is a pain in VB (few people do it), transaction enlistment is also a pain, and VB versioning of COM libraries is bad.
COM+ added automatic enlistment of distributed Tx (C++ can do this without COM+), role based secuity (it's not hard to do this in C++), Neutral Threading Model (not needed with C++ since you can create MTA objects anyway). All of those things were done for VB's benefit (and of course C++ could use them too). Of course COM+ also added LCE and queued componments, which you could write in C++ if you could be bothered.
The point is that MTS/COM+ made VB COM objects useful and added features that was impossible to do in VB. Thus I argue that COM+ was simply created to extend the lifetime of VB because fixing VB's poor hadling of COM would be too difficult.
(BTW COM+ did provide some new security features - cloaking and delegation - that were new to C++, but I would contest that they are minor compared to the features it added for VB)
Slashdot Mirror
>which I've kept around, and Lord knows if I'm allowed to share them (probably not). In them, I
> can see VC++ code WITH ATTRIBUTES, and this was in the VC6 days. Note that this version
> of the language NEVER SHIPPED, and primary development was moved over to Cool. The
Well, without knowing exactly what you are referring to I cannot argue with you. Mary's article did have C++ with attributes, isn't that what you are talking about?
I attended several C++ meetings at Microsoft in the timeframe you are talking about, and I did see some attributed C++, but I cannot remember the details (I've got my notes somewhere...). Of course, one of the aims of the VC team at that time was to produce attributed unmanaged C++, which did appear in VC7. And, of course, Managed C++ in VC7 is attributed. So when you say that an attributed version of C++ never shipped, well, several versions have shipped, but perhaps not the one that you saw in your powerpoints
> attributes in the sample code were mainly MTS-centric, which makes sense given the MSFT
> mindset at the time -- make developers more productive in a COM+MTS-activation world.
Don Box produced some 'attributed' C++ where the attributes were XML. Again, that was in the time frame you mention.
Oh well, its all history now.
> Looking back further still, the original COM+
.NET, not COM+ component services. Yes, the article title said COM+ but her article was about the client side runtime, which is what we now call .NET. What we now call COM+ is the server side runtime, and Mary's article was not about that.
Both MTS and COM+ 1.0 (and 1.5 in XP) use the catalog to contain information about configured objects. Unmanaged C++ did not have attributes (VC7 does but that's a code generation tool). Instead you had to apply configuration through the COM+ component services explorer, or write some convoluted OLE automation code. The reason why you have to write convoluted OLE automation code is that MTS and COM+ were (IMO) provided to fix the problems that VB6 had with COM. That is:
> was more like COM+ 2.0 (with attributed-based
> programming extensions to C++, no less), but
> that got scaled back and the shipping version
> of COM+ was more akin to COM+MTS.
Are you referring to Mary Kirtland's MSJ Dec 97 aricle? That was
1) It's pointless calling CoInitializeSecurity in VB
2) VB can only produce STA objects so has poor scaleability
Further, Win32 security is a pain in VB (few people do it), transaction enlistment is also a pain, and VB versioning of COM libraries is bad.
COM+ added automatic enlistment of distributed Tx (C++ can do this without COM+), role based secuity (it's not hard to do this in C++), Neutral Threading Model (not needed with C++ since you can create MTA objects anyway). All of those things were done for VB's benefit (and of course C++ could use them too). Of course COM+ also added LCE and queued componments, which you could write in C++ if you could be bothered.
The point is that MTS/COM+ made VB COM objects useful and added features that was impossible to do in VB. Thus I argue that COM+ was simply created to extend the lifetime of VB because fixing VB's poor hadling of COM would be too difficult. (BTW COM+ did provide some new security features - cloaking and delegation - that were new to C++, but I would contest that they are minor compared to the features it added for VB)
the link got broken in the editor, note that the name of the file is complus2.jpg (no space in it)
sigh here is a scan of one of the CDs I was sent at the end of December 1999 when I joined the COM+2 tech preview.
u s2.jpg
.NET runtime
http://www.grimes.demon.co.uk/dotnet/images/compl
On that CD is a readme.htm that gives a list of the files that will be installed. Here is the first few files in that list:
File List for COM+ 2.0
\%SYSTEM%\msdis110.dll
\%SYSTEM%\CORPerfMonSymbols.ini
\%SYSTEM%\CORPerfMonSymbols.h
\%SYSTEM%\CustomMarshalers.mod
\%SYSTEM%\System32\mscorsn.dll
\%SYSTEM%\mscoree.dll
\%SYSTEM%\mscoree.tlb
\%SYSTEM%\mscorrc.dll
\%SYSTEM%\System32\mscorlib.dll
Its clear from this that they are the files for the
So I am right about the name, will you now accept that I am right about the other stuff?