#184 Support for BOCOLE

[Vidar Hasfjord]

BOCOLE is the foundation for OCFNext, but has until now not been maintained, leaving OCFNext in a partly unusable state. This ticket aims to add support for building BOCOLE with modern C++, so that the library can be maintained, and hence make sure that OCFNext works well for all features for which it depends on BOCOLE, and thereby ensure that it can also be maintained in good working order into the future.

[Vidar Hasfjord]

Build support in OWLMaker should be added, with support for all the build configuration supported by OCFNext. BOCOLE does not need to be explicitly selectable as a separate module. It could be built automatically, as part of building OCFNext. However, it could be useful to be able to select and build the library separately.

[Vidar Hasfjord]

Obviously, with the ongoing changes, BOCOLE is no longer binary compatible with earlier versions, so how will that affect release targeting?

Since BOCOLE is an implementation detail for OCFNext, and we have not so far considered BOCOLE itself as part of our supported libraries, I guess it should be OK to include this major new support in the 6.44.15 maintenance update. In particular, since naming of the new updated BOCOLE libraries will be different, it shouldn't affect existing use of the old DLL.

I presume that the changes in BOCOLE will have no affect on OCFNext API and ABI, of course. If that is not the case, we'll have to target 6.45 and 7.1 for this ticket.

[Sebastian Ledesma]

So far [r5535] all changes are (should) be API & ABI compatible with the 'old-n-good' BOCOF.dll .
The 64 bit version obviously has more liberty in the ABI.

[Vidar Hasfjord]

So far [r5535] all changes are (should) be API & ABI compatible

Nice! Are you aiming for upgrading "BOCOF.DLL"? If so, would that be guaranteed to be binary compatible across compilers, or do you plan to restrict this particular fixed file name to be compiled only with a compatible compiler (classic BCC32)? Is the BOCOLE API/ABI pure C? If not, there could be incompatibilities across C++ ABIs for different compilers (exceptions, etc.).

Or do you plan wider compiler support, with a transition to a new naming scheme that differentiates between toolsets, platforms and build modes, similar to the rest of OWLNext, as I suggested in the discussion thread?

Just something to think about. I'll leave these decisions to you, as I am unlikely to get deeper involved in this, other than following your progress and doing casual review.

PS. By the way, I have updated all your log statements, that otherwise do not refer to a ticket (such as the bug ticket fixes) to refer to this ticket, making it clear (for all casual reviewers) that all your latest commits are part of your work on BOCOLE support. See log.

[Vidar Hasfjord]

In [r5535], your type change to "uCount" makes the name illogical (the prefix "u" is Hungerian notation for "unsigned", I presume). Also the for-statement is not indented properly (issue in the old code, not your changes). Suggested improvement:

for (LONG i = 0; i < menuGroupWidths.width [uGroup]; ++i)
  DeleteMenu (hMenuShared, uDeleteAt, MF_BYPOSITION);

[Vidar Hasfjord]

In [r5531], you update the version info for the DLL. For consistency, consider using the same version number, copyright etc. as the rest of OWLNext (see the version info in the other modules, which all refer to the OWL core, for simplicity).

For example, see "include/ocf/version.h" and "source/ocf/version.rc".

PS. The internal version number defined in "bolever.h" also needs updating. Consider automating it by including "ocf/version.h" — it has OCF_VERSION_64BIT (defined as OWL_VERSION_64BIT) that can be used to form BOLE_FILEVER_LS and BOLE_FILEVER_MS. However, note that BOLE_FILEVER_MS is not used in "bolever.cpp"; only BOLE_FILEVER_LS is inserted into VersionHeader structure, so perhaps they both can be replaced by OCF_VERSION_32BIT.

[Vidar Hasfjord]

Hi Sebastian,

I am preparing release of an update to 6.44. See [discussion:41c758a1f3].

Can you summarise the state of your work on this ticket here, please? If you are not ready for release now, we can temporarily undo your changes and retarget them for the next release. If so, I recommend that further work proceeds on the trunk until done. Then we can merge your changes to 6.44 and 7.0 and make another release.

[Sebastian Ledesma]

Hi:

Current BOCOLE changes are API and ABI compatible with standard OCFNext.
It includes two simple bugfixes in the original BOCOLE code.

Win32 ANSI BOCOLE -> works ok.

Win32 UNICODE BOCOLE -> builds but need time to be tested. Only affects to UNICODE apps, and they default to ANSI BOCOLE in case that the UNICODE BOCOLE it's not deployed in the app directory.

Win64 ANSI: complies ALL the source code. Most of the source code it's Win64 compatible but there at least one point where I'm pretty sure that there is pointer truncation.

Win64 UNICODE: same as Win64 ANSI.

Both version of Win64 can't be builded until I submit the new boleui64. I have simple file with some dummy functions.

The updated makefile also allows to build the static version of BOCOLE (just pass the parameter -DLIB or -DDLL=0 )

[Vidar Hasfjord]

Hi Sebastian,

Considering that your work is ongoing and not ready for release, I have undone it [r5584] and moved your changes to the trunk ([r5579] and [r5580]). I have also moved your work on related BOCOLE fixes ([bugs:#500] and [bugs:#501]), as well as related OCF code improvements ([r5553] and [r5554]), to the trunk ([r5581], [r5582] and [r5583]).

Please continue your work on the trunk. When ready for release, set all your related tickets to "pending" for review and release. If everything looks good, then we'll merge your changes back into the supported release branches (currently 6.44 and 7.0) and make new releases.

[Vidar Hasfjord]

I've made some preliminary fixes and workarounds to eliminate warnings in OCFNext in 64-bit build mode. See my comment in the new ticket for 64-bit OCFNext [feature-requests:#218]. Please consider taking ownership of the ticket, if you are working on, or need, 64-bit support in OCFNext.