In <list-938880@2rosenthals.com>, on 07/31/20
at 10:28 PM, "Dave Yeo" <cwmm-dev@2rosenthals.com> said:
Hi Dave,
>> WPTYPES.IDL:23
>> typedef unsigned long ULONG;
>OK, I've installed the VACPP 3.08 including all fixes that Lewis kindly
>donated, I still see in G:\IBMCPP\INCLUDE\OS2\WPTYPES.IDL having at line
>23, typedef int BOOL;
My advice is make the G:\IBMCPP\INCLUDE\OS2\ directory disappear and
forget it existed. The same is true for any other SOM components in
\IBMCPP that have been superceded by newer components in the Toolkit.
I apologize for taking so long to recall why this directory can exist. It
took some review of the VAC VACPP.PKG Software Installer Package file to
revive my memory. It's been over 20 years since I last had to think about
this directory. In software installer terms, the content of
IBMCPP\INCLUDE\OS2\ is part of
COMPONENT
NAME = 'Warp Toolkit Headers & Libraries',
ID = 'WARPHLIB',
This component existed because back in 1995 there was not yet a separately
delivered toolkit. When the toolkit appeared, I uninstalled the VAC
WARPHLIB component because to my form of common sense, keeping it around
could only cause problems. Also back in the 90's disk space was a bit
more of a scarce commodity.
The same applies to the VAC SOM Component
COMPONENT
NAME = 'SOM DLL',
ID = 'SOMDLL',
It too got uninstalled when the separately installed toolkit appeared.
The same thing applies to any copies of SOM .IR files that duplicate
copies in %_BOOT:\OS2\ETC. They sould be gone. Nothing good can come
from trying to use them.
This reminds me of an interesting feature of the VAC installer. Left to
its own devices, it would backlevel the SOM DLLs on the boot drive with:
Lars discovered some defects in the EMITC.DLL that shipped with the 4.5.2
toolkit. The fix is to use the EMITC.DLL from the 4.0 tooklit. It has
less defects.
Now that we have gone over all this, it's now obvious to me why you have
G:\IBMCPP\INCLUDE\OS2\WPTYPES.IDL having at line 23,
typedef int BOOL;
It's a defect in the version of WPTYPES.IDL that shipped with VAC. I
assume that the version of SC.EXE that shipped with VAC accepted accepted
this usage without complaining because it did not understand that this was
a defect. Someone must have noticed/reported this and the defect was
fixed in the toolkit versions of SC.EXE and WPTYPES.IDL and part of the
fix was to report the defective usage of int.
volver a la lista