Hi Pritpal,
> Again I say I agree with your view point.
>
> Long back, perhaps 2002, I initiated a lot of
> message about this very fact, on xHarbour NG,
> to streamline all WINAPI functionality in one
> common library. At that moment What32 was
> just came into being. I was puzzled and
> wondered why everyone is writing his own
> WINAPI modules, What32, HWGUI, MINIGUI,
> the then WHOOPGUI, and a lot more.
>
> Moreover I had requested all Windows developers
> to create a common API lib with a distinct namespace,
> OR to modify their libs to distinct name spaces,
> to make all of them usable in every application,
> but nobody cared. So I gave up. I changed namespace
> of What32 and kept it as local repository.
I fully endorse your idea. In Harbour we seem to
like these kind of clean things :)
One problem with the clean approach is that the
Windows API is huge and there is really nobody
interested in maintaining a full set of wrappers.
This is huge work and most ppl only need some
specific parts of it.
Regardless, given some rules and frame to this
problem, I think it isn't impossible to manage it.
> This is such a cheos that we are unable to use
> finest of all API developers in a single application, a pity.
Yes.
> Now as you have raised this topic again, I propose next
> logical evolution as :
>
> Higher level generic calls like:
> HB_FUNC( API_SETBKCOLOR )
> {
> #if defined( HB_OS_WIN )
> hb_retl( SetBkMode( ... ) );
> #elif defined( HB_LINUX )
> hb...
> #endif
> }
>
> The upper level API will form the basis of portable GUI
> in future.
Here I disagree as the Windows API isn't so good (in
fact it's a pretty weak one with a too long history) that
we choose it as the common denominator for all other
GUIs or APIs in general.
> May be I am not clear, but the idea can be discussed.
I understand you. I had similar concept in mind with hbwin.lib,
but not just for GUI, but for everything that is part of the
Windows API (registry, OLE, whatever, quite like hbwhat),
and without making an attempt to make it a multiplatform
compatibility lib at the same time. For convenience, the
Windows only functions may have a stub (returning permanent
error) when compiled for other platforms.
This doesn't mean however that another library couldn't
be built upon hbwin.lib (and others) to create any sort
of multiplatform solution, but IMO it's not the job of hbwin.lib.
To put it shortly: IMO hbwin should be a pure wrapper for
the Windows API and closely Windows API related features,
nothing more, nothing less. It's also important that
64-bit, Unicode and GCC/MSVC/POCC/OW compatibility be
kept here, and some other general code quality considerations
as well, like safe string operations, ANSI comments, and good
source file granularity.
Ideally I'd imagine below steps to clean up this situation:
1) Remove hbole.lib.
2) Move WIN_*() from GTWVG to hbwin.lib
3) Move WIN_*() from uhttpd to hbwin.lib
4) Disable hbwhat from mainstream builds (move to
examples) and start to move useful, tested and error-free
parts to hbwin.lib.
5) Further cleanup hbwin.lib (naming, better separation
of API, additional convenience functions and classes).
6) Remove hbwhat.lib altogether.
We should definitely avoid replicating hbwhat, so we
should concentrate on important functions, and implement
them well, instead of implementing everything and losing
track of them.
For future development a very simple rule can be added:
- If someone needs to access a Windows API function
from .prg code, look in hbwin.lib first, if it's there use it,
if not, implement it there using WIN_<winapi_name>()
naming scheme. Easier said than done I guess :) but
why not try it?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
