Hi, >>> If you only had not time to update some code for WinCE builds >>> then please at least leave a not about it or add iTODO warning. >>> Now seems that we have to verify all >>> #if [!] defined( HB_OS_WIN_CE ) >>> conditional compilation macros and mark the ones which cannot be >>> implemented due to limited WinCE API and the ones which can be >>> implemented but so far we had no time for it. >> Such guard in most cases is equivalent to "further >> check needed for WinCE". Unfortunately the topic >> is wide and very time consuming, so there was no >> precise research made for every function, ever >> committed to hbwin. > > So please leave a note that you haven't tested it adding such guard. > It will help other developer to locate places which have to be tested. > Now we have to repeated tests for things which were verified some time > ago. It will be also very good to add to such notes information about > used C compiler because there are some differences between them and it's > possible that some functions exists in MinGWCE but not in MSVC and some > other are only in MSVC.
Again: I've made no tests and most probably I won't. If you want I can mark new uses as such. But pls remember it's not my own code for the most part, so we need to develop some generic workflow for this. Maybe HB_OS_WIN_CE_TOCHECK can be added for this purpose, it seems better than some free text comment. I'd estimate even this will be pretty difficult to enforce for committers, from hard-learned paste experience. >> I think we should keep this behavior, since for .prg >> level function is better to not pass over the whole >> ugliness of low-level WinCE programming, plus .prg >> code doesn't really have the tools to verify the exact >> low-level details (compiler version, API version, etc). > > IMO the only one thing which is good is sth what helps Harbour users. > If sth creates problems for them without any significant improvements > then we should not force such solutions. Not working PRG functions > without any information that they are not implemented yet just to only > hide link time errors is the worst possible choice. > It does not help anyone. It only hides real problems. I'm not convinced. It's hbwin/WinCE developers job to solve such problems for WinCE users, if it's possible to solve. If it's not possible to solve, we can chose from above solutions, but creating different link errors depending on what C compiler is used by .prg level programmer is not a very good idea at all. Harbour's job is to hide platform/compiler differences, not to pass them to .prg programmers. This is one of our major goal. If this is impossible to achieve, it's also an option to simply not implement those incriminated functions in hbwin at all, on the base that they're not portable. Even if it sounds funny that WinCE has portability problems on its own. Which it apparently has. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
