BlackBox Framework Center

I have created issue #23 for fixing bugs in WinApi plus some extensions.
The bug fixes and the extensions to WinApi are as proposed by Helmut Zinn and Koen Desaeger
in CPC 1.7 rc4.

The proposal looks good to me.
The only open points for me are:

(1) how to proceed with the new entries
that are commented out and marked by xxx.

(2) how to proceed with the folds that have been introduced for the default
variant of a procedure, which is, like in 1.6, set to the ascii version if there
is an ascii version and a unicode version of the same procedure.
As long as all folds are expanded during compilation, there is no
change in the WinApi. If the folds are collapsed during compilation, the default
version would disappear, which may and most probably will break existing code.

If you look at the list of changes, most are related to the fold elems.
http://redmine.blackboxframework.org/pr ... od/Api.odc

- Josef

Josef Templ wrote:If the folds are collapsed during compilation, the default
version would disappear, which may and most probably will break existing code.

I have checked that removing of this procedures will not break existing BlackBox code. Maybe this will break some components code, but for new 1.7 version we have rights to break a bit the compatibility with 1.6.

Breaking existing code is not restricted to the BlackBox sources themselves.
There may be code outside BlackBox that will break but there is no real benefit
from breaking such code. I mean, it is not an incompatibility that is forced by a
bug fix or any significant enhancement.

- Josef

Josef Templ wrote:Breaking existing code is not restricted to the BlackBox sources themselves.
There may be code outside BlackBox that will break but there is no real benefit
from breaking such code. I mean, it is not an incompatibility that is forced by a
bug fix or any significant enhancement.

- Josef

I agree, in such case folds should be removed.

regarding the comments marked xxx in the CPC 1.7 rc4 version of WinApi:
I think, these should be added because they are intended to be
used as parameters of SetWindowPos according to the docu in msdn.
In HostWindows, for example, the constants are used in a hard coded form plus comments,
which shows that the definitions are really missing in WinApi.
HKEY_PERFOMANCE_DATA and HKEY_CURRENT_CONFIG can be added.
HKEY_DYN_DATA is only used for Win95/98/ME, so it should be removed.
The typo in HKEY_PERFOMANCE_DATA should be fixed to HKEY_PERFORMANCE_DATA.
These should not be added. They refer to a dll that is not used otherwise.
The dll is also in an unclear state with respect to different Windows versions.
The dll is quite large (under Vista 345 KB) and I don't know what happens at BB
startup with such dlls. Does it slow down startup? Does it increase the process size?
Or is this dll mapped anyway because it is imported from another dll?
(Just looked it up under Vista: it is mapped anyway, so the overhead is very small, at least under Vista).
There are also many more functions in this dll, so supporting just the two of them is
very special.

Helmut, what do you think?
Did you look at the xxx? Where do they come from originally?

- Josef

Josef,
we should do it in the way as you wrote. I agree.

Some further comment about BlackBox, Windows & WinApi:

The Windows 95, 98 and XP are obsolete.
BlackBox 1.5 uses WinApi.xxxA calls and runs on Windows 95 & 98. It does not support Unicode, because the A calls work with ASCII.
BlackBox 1.6 uses WinApi.xxxW calls and can’t run with 95 & 98. It supports Unicode, because the W calls work with Unicode.
Should we delete the old obsolete old ASCII calls in the WinApi (collapse the fold and delete all folds) ?

There are other more important active changes in the WinApi. Do you take over all those changes too?

And there are some other changes in comment which should be discuss.
e.g.
lfItalic*: SHORTCHAR; (* BOOLEAN; *)
lfUnderline*: SHORTCHAR; (* BOOLEAN; *);
lfStrikeOut*: SHORTCHAR; (* BOOLEAN; *);

PROCEDURE Polyline* ["GDI32.dll", ""] (p0: HDC; VAR [nil] p1: (* ARRAY [untagged] OF *) POINT; p2: INTEGER): BOOL;

The changes of WinApi supposed from Koen Desaeger, Ivan N. Goryachev and Fyodor V. Tkachov a very long time ago.
- Helmut

the added comments are of course preserved.

I have added the appropriate "xxx" definitions and I have also added
one more function that was under comments (SetFilePointerEx) with minor required adaptations
according to msdn.

Revision c5da3f57 Win/Mod/Api.odc

The remaining question is how to proceed with the folds.
Technically, it would be easy to remove the folds.
It would also be easy to reconstruct the folds later on because we have a version with folds in the repository.

My preference would be to remove the folds that were introduced in CPC 1.7 rc4, that is, to use the BB 1.6 style of WinApi.
This simplifies reading and understanding of WinApi and it removes about 500 differences
which are no real differences in the redmine diff viewer.
@Helmut: you have invested a lot of time into the folds. Is it OK for you to remove the (expanded) fold elems?
I really don't want to destroy anybodies hard work. So please comment on that.

- Josef

Looking to the future when BB is platform independent the WinApi should be subsumed within the 'Host' convention.

The Host subsystem contains host specific implementations of generic APIs.
HostFiles provides an implementation for Files, for example.
This does not apply to WinApi. The subsystem Win provides only
the interfaces to the underlying Windows platform.
Besides that, this kind of subsystem structure change would be a HUGE change.
I would definitely not support it because it does not solve any problem.

- Josef

There was some discussion about the shlwapi dll.

I personally use the procedures PathFindOnPathW & PathFileExistsW.


It seems to me that access to useful procedures that already exist in the operating system should:

- Either be provided

- Or, if there is a reason not to use them, the reason should be explained, and an alternative / better solution provided.


Of course, if very few people use this (and other Windows dlls?) the "right" solution may be to make the inteface available as an optional library (on CPC ?) rather than as part of a "standard" BlackBox distribution.


- Robert