is _bstr_t not defined in Watcom ?

[Lynn McGuire]

I am trying to compile some of my Visual Studio code in OW 1.9. My COM
code references the function _bstr_t. I cannot seem to find this
function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

Here is the code:

OLEMethod (DISPATCH_PROPERTYGET, & result1, pExcelApplication,
L"ActiveWorkbook",
"Getting the pointer of the active spreadsheet
(GetExcelCurrentSelection)", 0);
if (result1.vt == VT_DISPATCH)
{
IDispatch *pDisp = result1.pdispVal;
VARIANT result2;
VariantInit ( & result2);
OLEMethod (DISPATCH_PROPERTYGET, & result2, pDisp, L"Name",
"Getting the name of the active spreadsheet
(GetExcelCurrentSelection)", 0);
if (result2.vt == VT_BSTR)
{
selection += "\'[";
selection += _bstr_t (result2.bstrVal);
selection += "]";
VariantClear ( & result2);
}
pDisp -> Release ();
}

Thanks,
Lynn

[Lynn McGuire]

I am trying to compile some of my Visual Studio code in OW 1.9.  My COM
code references the function _bstr_t.  I cannot seem to find this
function in OW.
   https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx
   OLEMethod (DISPATCH_PROPERTYGET, & result1, pExcelApplication,
              L"ActiveWorkbook",
              "Getting the pointer of the active spreadsheet
(GetExcelCurrentSelection)", 0);
   if (result1.vt == VT_DISPATCH)
   {
      IDispatch *pDisp = result1.pdispVal;
      VARIANT result2;
      VariantInit ( & result2);
      OLEMethod (DISPATCH_PROPERTYGET, & result2, pDisp, L"Name",
                 "Getting the name of the active spreadsheet
(GetExcelCurrentSelection)", 0);
      if (result2.vt == VT_BSTR)
      {
         selection += "\'[";
         selection += _bstr_t (result2.bstrVal);
         selection += "]";
         VariantClear ( & result2);
      }
      pDisp -> Release ();
   }
Thanks,
Lynn

_bstr_t_ is fundamental to converting OLE2 Variant strings into std::string.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

Lynn

[Paul S. Person]

On Thu, 2 Aug 2018 16:29:18 -0500, Lynn McGuire

Post by Lynn McGuire
I am trying to compile some of my Visual Studio code in OW 1.9. My COM
code references the function _bstr_t. I cannot seem to find this
function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

I have /no/ relevent experience with "COM, Automation, and Interop
functions", but _bstr_t appears to be a /class/, not a function.

Perhaps this is also relevant:

Header: comutil.h

Lib: comsuppw.lib or comsuppwd.lib

[Lynn McGuire]

Post by Paul S. Person
On Thu, 2 Aug 2018 16:29:18 -0500, Lynn McGuire

Post by Lynn McGuire
I am trying to compile some of my Visual Studio code in OW 1.9. My COM
code references the function _bstr_t. I cannot seem to find this
function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

I have /no/ relevent experience with "COM, Automation, and Interop
functions", but _bstr_t appears to be a /class/, not a function.
Header: comutil.h
Lib: comsuppw.lib or comsuppwd.lib

Yes, _bstr_t is in a class but there is code in a library also.

I munged up Microsoft's comutil.h and got it to compile with much
effort. But then I got a bunch of com_* undefines in the link. The
UTF8 undefines are ours.

C:\dii_15>linkdiid
Could Not Find C:\dii_15\designii.dll
Open Watcom Linker Version 1.9
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
Error! E2028: int near UTF8toWide( char const near *,
std::basic_string<wchar_t near,std::char_traits<wchar_t near >
near,std::allocator<wchar_t near > near > near & ) is an undefined reference
Error! E2028: int near fopen_s_UTF8( __iobuf near * near *, char const
near *, char const near *, int ) is an undefined reference
Error! E2028: void near _com_issue_error( long ) is an undefined reference
Error! E2028: char near * near _com_util::ConvertBSTRToString( wchar_t
near * ) is an undefined reference
Error! E2028: wchar_t near * near _com_util::ConvertStringToBSTR( char
const near * ) is an undefined reference
Error! E2028: std::basic_string<char near,std::char_traits<char near >
near,std::allocator<char near > near > near SetUnitsCase(
std::basic_string<char near,std::char_traits<char near >
near,std::allocator<char near > near > ) is an undefined reference
creating map file
creating a Windows NT dynamic link library
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol int near UTF8toWide( char const near *, std::basic_string<wchar_t
near,std::char_traits<wchar_t near > near,std::allocator<wchar_t near >
near > near & )
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol int near fopen_s_UTF8( __iobuf near * near *, char const near *,
char const near *, int )
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol void near _com_issue_error( long )
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol char near * near _com_util::ConvertBSTRToString( wchar_t near * )
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol wchar_t near * near _com_util::ConvertStringToBSTR( char const
near * )
file fm2nbook\fm2n_old.obj(C:\dii_15\fm2nbook\fm2n_old.cpp): undefined
symbol std::basic_string<char near,std::char_traits<char near >
near,std::allocator<char near > near > near SetUnitsCase(
std::basic_string<char near,std::char_traits<char near >
near,std::allocator<char near > near > )
Could Not Find C:\dii_15\designii.lib
Open Watcom Library Manager Version 1.9
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! Cannot open 'designii.lib' - library will be created
Error! Cannot find file 'designii.dll'

Thanks,
Lynn

[Paul S. Person]

On Fri, 3 Aug 2018 14:05:32 -0500, Lynn McGuire

Post by Lynn McGuire

Post by Paul S. Person
On Thu, 2 Aug 2018 16:29:18 -0500, Lynn McGuire

Post by Lynn McGuire
I am trying to compile some of my Visual Studio code in OW 1.9. My COM
code references the function _bstr_t. I cannot seem to find this
function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

I have /no/ relevent experience with "COM, Automation, and Interop
functions", but _bstr_t appears to be a /class/, not a function.
Header: comutil.h
Lib: comsuppw.lib or comsuppwd.lib

Yes, _bstr_t is in a class but there is code in a library also.

Well, of course there is code /somewhere/: the class has to be
implemented, does it not?

And have you tried /using/ the libraries? Which are, presumably,
intended to help link to DLLs?

It appears to me that you are dealing here with Microsoft stuff, not
Watcom stuff. All you should need to do is get the interface right, as
with any other Microsoft API.

[Johann Klammer]

I am trying to compile some of my Visual Studio code in OW 1.9. My COM code references the function _bstr_t. I cannot seem to find this function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx
OLEMethod (DISPATCH_PROPERTYGET, & result1, pExcelApplication,
L"ActiveWorkbook",
"Getting the pointer of the active spreadsheet (GetExcelCurrentSelection)", 0);
if (result1.vt == VT_DISPATCH)
{
IDispatch *pDisp = result1.pdispVal;
VARIANT result2;
VariantInit ( & result2);
OLEMethod (DISPATCH_PROPERTYGET, & result2, pDisp, L"Name",
"Getting the name of the active spreadsheet (GetExcelCurrentSelection)", 0);
if (result2.vt == VT_BSTR)
{
selection += "\'[";
selection += _bstr_t (result2.bstrVal);
selection += "]";
VariantClear ( & result2);
}
pDisp -> Release ();
}
Thanks,
Lynn

Hmmm. wasn't there some general rule to avoid types
starting in _ because those are implementation specific?

[Paul S. Person]

On Fri, 03 Aug 2018 20:39:17 +0200, Johann Klammer

Post by Johann Klammer

I am trying to compile some of my Visual Studio code in OW 1.9. My COM code references the function _bstr_t. I cannot seem to find this function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx
OLEMethod (DISPATCH_PROPERTYGET, & result1, pExcelApplication,
L"ActiveWorkbook",
"Getting the pointer of the active spreadsheet (GetExcelCurrentSelection)", 0);
if (result1.vt == VT_DISPATCH)
{
IDispatch *pDisp = result1.pdispVal;
VARIANT result2;
VariantInit ( & result2);
OLEMethod (DISPATCH_PROPERTYGET, & result2, pDisp, L"Name",
"Getting the name of the active spreadsheet (GetExcelCurrentSelection)", 0);
if (result2.vt == VT_BSTR)
{
selection += "\'[";
selection += _bstr_t (result2.bstrVal);
selection += "]";
VariantClear ( & result2);
}
pDisp -> Release ();
}
Thanks,
Lynn

Hmmm. wasn't there some general rule to avoid types
starting in _ because those are implementation specific?

I have /no/ experience working with this sort of thing, but it appears
to me that the /entire thing/ is specific to Microsoft, so why should
_bstr_t be any different?

[Steven Levine]

On Sat, 4 Aug 2018 16:33:55 UTC, Paul S. Person
<***@ix.netscom.com.invalid> wrote:

Hi guys,

Post by Paul S. Person

Post by Johann Klammer

I am trying to compile some of my Visual Studio code in OW 1.9. My COM code references the function _bstr_t. I cannot seem to find this function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

Hmmm. wasn't there some general rule to avoid types
starting in _ because those are implementation specific?

I have /no/ experience working with this sort of thing, but it appears
to me that the /entire thing/ is specific to Microsoft, so why should
_bstr_t be any different?

Nor to do. However, it seems to me that if _bstr_t is an OLE2
specific class/type one is going to need an OLE2 SDK to build a
working OLE2 app and that the SDK will provide the needed headers.

Best I can tell, OpenWatcom does not ship with a current OLE2 SDK.
This is not to say that OpenWatcom knows nothing about OLE. A search
of the sources finds:

bld\w32api.old\include\ole.h
bld\w32api.old\include\ole2.h
bld\w32api.old\include\ole2ver.h
bld\w32api.old\include\oleacc.h
bld\w32api.old\include\oleauto.h
bld\w32api.old\include\olectl.h
bld\w32api.old\include\olectlid.h
bld\w32api.old\include\oledlg.h
bld\w32api.old\include\oleidl.h
bld\w32api.old\lib\oleacc-uuid.c
bld\w32api.old\lib\olectlid-uuid.c
bld\w32api.old\lib\oleidl-uuid.c

However, I suspect this code is not useful for much.

Steven

[Lynn McGuire]

Post by Steven Levine
On Sat, 4 Aug 2018 16:33:55 UTC, Paul S. Person
Hi guys,

Post by Paul S. Person

Post by Johann Klammer

I am trying to compile some of my Visual Studio code in OW 1.9. My COM code references the function _bstr_t. I cannot seem to find this function in OW.
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx

Hmmm. wasn't there some general rule to avoid types
starting in _ because those are implementation specific?

I have /no/ experience working with this sort of thing, but it appears
to me that the /entire thing/ is specific to Microsoft, so why should
_bstr_t be any different?

Nor to do. However, it seems to me that if _bstr_t is an OLE2
specific class/type one is going to need an OLE2 SDK to build a
working OLE2 app and that the SDK will provide the needed headers.
Best I can tell, OpenWatcom does not ship with a current OLE2 SDK.
This is not to say that OpenWatcom knows nothing about OLE. A search
bld\w32api.old\include\ole.h
bld\w32api.old\include\ole2.h
bld\w32api.old\include\ole2ver.h
bld\w32api.old\include\oleacc.h
bld\w32api.old\include\oleauto.h
bld\w32api.old\include\olectl.h
bld\w32api.old\include\olectlid.h
bld\w32api.old\include\oledlg.h
bld\w32api.old\include\oleidl.h
bld\w32api.old\lib\oleacc-uuid.c
bld\w32api.old\lib\olectlid-uuid.c
bld\w32api.old\lib\oleidl-uuid.c
However, I suspect this code is not useful for much.
Steven

Yes, OW is sadly getting out of date.

Lynn

[Paul S. Person]

On Mon, 6 Aug 2018 14:12:19 -0500, Lynn McGuire

Post by Lynn McGuire
Yes, OW is sadly getting out of date.

While I can understand this viewpoint,
I don't see that OW has any obligation to support vendor-specific APIs
at all
except, of course, by being able to link to their libraries -- that
is, to resolve any calling convention issues.

The commercial product was, IIRC, in direct competition with the
Microsoft compilers, and so had some reason to support
Microsoft-specific APIs. But OW does not, IMHO, beyond what I said
above.

Have you tried linking with the libraries listed in the web page you
cited? If they are (as I suspect) used to link to DLLs, have you tried
generaing equivalent libraries with wlib (or wlink? it's been so long
since I did anything like this that I have forgotten), which would use
the same "decoration" as the OW compiler/linker?

[Lynn McGuire]

Post by Paul S. Person
On Mon, 6 Aug 2018 14:12:19 -0500, Lynn McGuire

Post by Lynn McGuire
Yes, OW is sadly getting out of date.

While I can understand this viewpoint,
I don't see that OW has any obligation to support vendor-specific APIs
at all
except, of course, by being able to link to their libraries -- that
is, to resolve any calling convention issues.
The commercial product was, IIRC, in direct competition with the
Microsoft compilers, and so had some reason to support
Microsoft-specific APIs. But OW does not, IMHO, beyond what I said
above.
Have you tried linking with the libraries listed in the web page you
cited? If they are (as I suspect) used to link to DLLs, have you tried
generaing equivalent libraries with wlib (or wlink? it's been so long
since I did anything like this that I have forgotten), which would use
the same "decoration" as the OW compiler/linker?

I wrote my own _bstr_t method (not finished yet as I need to see who is
calling it).

#ifdef __WATCOMC__

// from comutil.h
class _bstr_t;

// Construct a _bstr_t from a const whar_t*
//
std::string _bstr_t (const wchar_t * s)
// : m_Data(new Data_t(s))
{
// if (m_Data == NULL) {
// _com_issue_error(E_OUTOFMEMORY);
// }

alert ("The Watcom C version of _bstr_t was called !");

return "";
}

#endif

And I replaced the critical _bstr_t calls with modified code to use
BSTRs directly:

// UTF-8 to wide
std::wstring wnewSheetName;
UTF8toWide (newSheetName.c_str (), wnewSheetName);
// the _bstr_t does not work with Watcom C++ so use BSTR
// _bstr_t sheetNameNewBstr = _bstr_t (newSheetName.c_str ());
BSTR sheetNameNewBstr = SysAllocString (wnewSheetName.c_str ());
fnameNew.bstrVal = sheetNameNewBstr;
OLEMethod (DISPATCH_PROPERTYPUT, & result4, pExcelSheet, L"Name",
"Set the name of the new sheet in the active spreadsheet
(ConnectToNewSheet)", 1, fnameNew);
int res = result4.vt;
VariantClear ( & fnameNew);

Thanks,
Lynn

[Lynn McGuire]

Post by Paul S. Person
On Mon, 6 Aug 2018 14:12:19 -0500, Lynn McGuire

Post by Lynn McGuire
Yes, OW is sadly getting out of date.

While I can understand this viewpoint,
I don't see that OW has any obligation to support vendor-specific APIs
at all
except, of course, by being able to link to their libraries -- that
is, to resolve any calling convention issues.
The commercial product was, IIRC, in direct competition with the
Microsoft compilers, and so had some reason to support
Microsoft-specific APIs. But OW does not, IMHO, beyond what I said
above.
Have you tried linking with the libraries listed in the web page you
cited? If they are (as I suspect) used to link to DLLs, have you tried
generaing equivalent libraries with wlib (or wlink? it's been so long
since I did anything like this that I have forgotten), which would use
the same "decoration" as the OW compiler/linker?

BTW, Simply Fortran uses gfortran and gcc and supports _bstr_t calls.
We will be evaluating it soon when we get some breathing room.
http://simplyfortran.com/

We also need the significantly improved math code.

Thanks,
Lynn