> > >> Ok for using *.ch, *.h, but if it is possible, to see immediately where > put a new addition, as per c api file I would like to mantain ms naming > convention, so for me it will be better to use, f.e., w_winuser.ch or > winuserapi.ch
We can do this. I personally prefer "w_winuser.ch". Or, what about: "wapi_winuser.ch"? To be in complete sync, maybe WAPI_*() prefix could be used for functions, too. Or, "winapi_winuser.ch" and WINAPI_*(). What do you think? > 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. >> >> > it will be good Okay. Does the group have any objection, opinions on above problem, especially with regards to allowing long filenames in directory /contrib/hbwin ? (and only there) > 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. >> >> yes, but should be verified because this will give a useful tool more > readable and more near to ms approach and it can make easier to move ms > code, IMO. Absolutely. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
