|Gönderim Listesi firstname.lastname@example.org Ar?vli ?leti #39||listeye geri dön|
On 07/31/20 11:45 PM, Steven Levine wrote:
In <email@example.com>, on 07/31/20
at 10:28 PM, "Dave Yeo" <firstname.lastname@example.org> said:
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.
OK. My original env script put the 4.52 toolkit ahead of VACPP, which I'd think did the same thing.
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
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
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.
OK. It did take a bit for me to remember to edit the config.sys before rebooting to make sure the VACPP stuff wasn't at the head of LIBPATH, PATH etc. First try resulted in a pure blue screen where only CTRL-ALT-DEL worked to reboot :)
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:
EXITWHEN = '"%TARGET%" == REMOTE',
EXITIGNOREERR = 'YES',
EXIT = 'REPLMOD %EPFIBOOTDRIVE%:\IBMCPP\DLL\SOM.DLL'
and so on. Like I said before, nothing good could come of this.
This didn't happen here luckily. All \os2\dll files are dated newer.
Review SOM\LIB in your tooklit and make sure you are using the
4-27-98 12:35 49,425 0 EMITC.DLL
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
Which leads to, where to get the 4.0 toolkit?
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.
So which toolkit to use? As noted earlier, I was running into problems with a Warp V4 define.
I was hoping to reproduce Chris's environment to start with. Unluckily he didn't really follow the rules and there's those hand written hh files
Abone ol: Bildirim,
Liste Sorumlusuna Postala