On 8/02/2021 19:43, Bruce Axtens wrote:
I still would like to find a way to write either a COM <https://en.wikipedia.org/wiki/Component_Object_Model> consumer or a COM provider in GnuCOBOL. It's been floating around in my mind for years but
I haven't got very far with it at all.
There's a discussion about it on the MASM32 forum. I'm not sure if you
can read
<http://masm32.com/board/index.php?topic=4153.msg44279#msg44279> without board membership.
Having said all that, I'm not sure what one would do with the facility
even if one had it given Microsoft's purported downplaying but ongoing
use of COM.
Bruce/bugmagnet
Hi Bruce,
Here's my take on MS COM:
1. Despite MS trying to talk it down (they would prefer that people use
.Net functions to build components), they themselves are so committed to
it that they are really unable to close it down. For example, they would
need to rewrite the Windows OS from scratch to remove it. Now that
Windows is Open Source, it might be possible to do that but I haven't
seen any serious effort from outside of MS (or from inside it for that matter...) I just ran an OLE object browser for fun, to see how many COM components are registered on my system... 668 :-) (Around 200 of them
are an integral part of Windowss 10...)
It isn't just the OS; COM has been a fundamental part of ALL their
packages. Anything that MS refer to as an "Automation Server" or an
"OLE" or "ActiveX" control, relies on COM. That's Word, Excel, and most
of MS Office... There are many thousands of components produced by 3rd
parties, and they rely on the COM interface to sell their products
across platforms. I don't believe it is going away soon...
2. Both Fujitsu and Micro Focus COBOLs support COM so it has been
possible to build sharable components in these languages for a couple of decades now. (I've been doing it for over 25 years; as soon as the penny dropped and I realized that component based design and development is
the ideal way to go for Networked applications. See
https://primacomputing.co.nz/primametro/ObjectsandLayers2.aspx
Components can be more easily "objectified" and are much smaller than, integrated code.)
3. Components written to be COM compliant have a standard interface that
can be recognized by other languages, and the resulting components can
also be rendered by web browsers. There is a free download on the PRIMA
site, which demonstrates using a COM component (written in COBOL) on the desktop AND from a web page...
4. Many years back I explained to the GnuCOBOL people that for me to use
their product commercially (and I would really LOVE to do that...), it
would need to have COM support in it, and it would need RDB support. The
RDB support has been addressed but the COM never has, and, consequently,
PRIMA never was able to use GnuCOBOL. Now it is moot because we have
moved on to C# (where I still write COM components easily, with good
support from the Language, Visual Studio, and the Community.)
Even though it is now too late for us, I'd still like to see GnuCOBOL supporting COM, because it would encourage some developers to write
COBOL components. I think it hasn't happened because most COBOL
programmers are unfamiliar with the concept of using cross-platform, cross-language, sharable components.
Pete.
--
I used to write *COBOL*; now I can do *anything*...
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)