[Harbour] SF.net SVN: harbour-project:[10164] trunk/harbour

[Viktor Szakáts]

Hi Francesco, Pritpal,

5) Further cleanup hbwin.lib (naming, better separation   of API, additional
>> convenience functions and classes).
>> 6) Remove hbwhat.lib altogether.
>>
>>
> sorry to jump in and probably missing some infos, but only as suggestion
> may I propose to adopt this naming convention:


In contrary, I'm happy you've joined the thread :)


> 1) replicate, as possible, windows dll api into a single file, i.e.
> w_gdi32.c, w_kern32.c (or such similar name) in which we know we can add API
> as described in MSDN structure.


Sounds good.


> 2) using, as above, header defines in *.api files (winuser.api, wingdi.api)


Here I don't agree, because usually I find it better
to use standard extensions, so if something is a
header I think we should stick with .ch, .h.

[ .api is reserved for Clipper legacy C headers,
and besides that, it's unclear by the name whether
they are meant for C or .prg code. ]

Since original Windows headers are a relatively
big mess, maybe it would be better not to replicate
it in hbwin.lib, but rather use one unified version,
hbwin.ch and hbwin.h. This is what we already do now.

If whole group agrees, and if that can help on the
file naming situation, we may lift the 8.3 chars naming
restriction for hbwin.lib. It's important to see however,
that DOS builds will be unable to compile hbwin.lib,
so despite any stubs implemented, DOS apps will
have to do without hbwin.lib functions, and they'll
definitely need to guard them with __PLATFORM__WINDOWS.

3) using, as namespace, WIN_API_*() as pure api wrapper and WIN_*() for
> "rearranged" C functions


Good idea. Maybe WINAPI_*() would be even better.


> 4) as possible, but has to be well tested, using STRUCTURES as per Pritpal
> proposal


Yes, well tested, portable, MT ready, alignment independent,
free from accessing Harbour internals, etc. IOW, if it can be done
in core quality, it's okay, if not however, it wouldn't be good to
build the whole lib upon it.

Brgds,
Viktor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.harbour-project.org/pipermail/harbour/attachments/20090204/44acef1b/attachment.html