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
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
