Mailing List Archived Message #41

From: "Dave Yeo" <> Full Headers
Undecoded message
Subject: Re: [cwmm-dev] Compiling cwwm
Date: Sun, 2 Aug 2020 09:31:23 -0700
To: CWMM Developers Mailing List <>

On 08/01/20 10:53 PM, Steven Levine wrote:
In <>, on 08/01/20
   at 07:47 PM, "Dave Yeo" <> said:

Hi Dave,

OK. My original env script put the 4.52 toolkit ahead of VACPP, which
I'd think did the same thing.

As I said, gone is better.  Less chance for it to accidentally get used.
If you cannot bear to delete the directories even though you have backups
of the content, rename the directory.  Consider how much time getting to
the point has cost.

Ok, zipped and deleted.

This didn't happen here luckily. All \os2\dll files are dated newer.

Well my understanding is that you did not do a standard install of 3.0
followed by a standard install of FP8.  Is this true?

I did a standard install of 3.0, then the updates in the root of the updates 7z, then fp8. All times I just entered enter.
While the oldest files in all my os2\dll's seem to from VACPP 3.0, they're all dated 1999 with older copyrights, eg som.dll-Copyright IBM 1992,1994

Which leads to, where to get the 4.0 toolkit?

You don't want the 4.0 toolkit.  You want EMITC.DLL from the 4.0 toolkit.
I will provide a copy, if Lewis cannot track one down.

OK, I found a copy on Developer Connection Volume 12. Same size but dated Feb 5 1996.

So which toolkit to use?

4.5.2 with updates.  It's got the fewest known defects.

OK, I believe that is what I have. IIRC, it came with eCS and I found a bug or 2 that Alex fixed.
I guess I should try to get Sylvan to add the SOM stuff to the Bitwise release which is also installed in @UNIXROOT.

As noted earlier, I was running into problems
with a Warp V4 define.

We now understand why.

At the worst, I'll have to add the define.

I was hoping to reproduce Chris's environment to start with.

I don't know about you, but I cannot think of any reliable or effective
way to duplicate an undocumented environment.

True, I was hoping to hit on the toolkit he used. Now just browsing the Developer Connection, there seems to be a lot of toolkits.

he didn't really follow the rules and there's those hand written hh files.

As I mentioned IBM states that it's OK to write the .hh files by hand.
The purpose of DTS is to eliminate the need for .idl files and sc.exe.  It
stands to reason that new .hh files would be coded by hand.  To help with
the transition to DTS, IBM enhanced sc.exe so that it could generate the
.hh file when an .idl file happened to be available.

OK, after wife time, I'll revisit.

This email was Anti Virus checked by Astaro Security Gateway.

Subscribe: Feed, Digest, Index.
Mail to ListMaster