Hi Przemek,
Dont' you afraid that we will end with winvista, winxp,
win9x, win64 and other subdirectories?
No. WinCE is a different beast than the rest of
the flavors, as you must know the best. We also have
the special macro HB_WINCE internally for this reason.
I do not agree. The differences between WinCE API and WinXP
are smaller then between Win9x and WinXP.
In our contrib code number of MS-Windows API functions which
does not exists in Win9x is systematically growing up and here
the problem is bigger the with WinCE and if we do not begin
to check it then we lost Win9x and NT4 compatibility in the
nearest future.
I don't really understand this. There could be
whatever API difference between Win95 and WinXP,
but the subset Harbour actually uses from them
is perfectly compatible. (except Unicode, which
is off by default anyway). We have just a few
code parts dealing with stuff only present on one
OS (diskspace, OS version) AFAIK. Anyhow, one
Harbour build works perfectly on both OSes.
Same can hardly be said on WinCE, which needs
wholly different APIs sometimes, emulation of
non-existent APIs, no driver letter, no registry,
no MT, completely different issues and priorities.
As far as contribs are concerned I don't know,
it's difficult to tell in general, but so far
it doesn't seem to be a need in any contrib to
make a difference by Win9x support. Even it
would be, this few cases could be covered with
some internal version checking just like when
checking for libcurl or ADS version.
So, pls don't see this as the start of something
which goes into a chaos where all minor flavors
of Windows is becoming a different Harbour platform.
I'd change w32 to simply win as a next step, and win
should cover all desktop flavors. Maybe we could
separate win32 and win64, but so far I cannot see
any strong reason to do it and it'd be better trying
to avoid this anyway in the future.
Now the biggest problem is only with Win9x for which we do
not even have build time setting to force Win9x compatibility.
Please tell me more about where this is an
actual problem?
[ but we may also want to introduce a 3rd level of
builds: real architecture, like x86, x64, ia32, ia64,
this would make it easier to create such builds in
parallel. no very high priority. ]
The achitucture problem is not real problem for us because
you need separated biunaries for each architecutre so you have
to rebuild harbour with different arch switches. The real problem
is in used MS-Windows API functions. To support new feature we
have to use new functions. But there is no easy way to now compile
Harbour code excluding all stuff which does not exists in Win9x.
In some cases where C compilers supports some dummy libraries
with dummy functions for Win9x then it we are trying to detect
use OS at runtime but such method does not work in all cases.
Yes, the only place where this could be important
is if we'd like to support multiple CPU builds in
parallel. Harbour went into great complications to
support different platform builds in parallel, but
this ends when it comes to CPU architecture. The
concepts, reasons and needs are exactly the same
for CPU targets. Right now I have to do a 'clean'
and a _full rebuild_ to switch between MSVC x64 and
MSVC x86 (unless I'm using some hacks) (same goes
for Win32 and WinCE), and this may not be a problem
for most ppl and/or yet, it makes parallel development
much more difficult and slow than it's necessary.
Well, gtwvg, hbwhat, hbtpathy f.e. don't have 3rd party
dependencies, yet they cannot be compiled and there don't
seem to be anyone taking care of this, but we certainly
cannot be sure they'll be ever fixed, if a fix is possible
at all.
Just like we cannot be sure that they will work with Win9x
in a year if we will keep current code updating and like you
do not know what will happen with incoming Win7. It's possible
that MS will force UNICODE builds for some new Windows version
just like it did for WinCE. As I can see then WinCE is quite
often updated and many of its modifications are later intorduced
to desktop windows so keeping the code ready for WinCE is very
good idea to make it ready for new desktop windows. Here I do
not see any problems with current build process and I like that
it forces some modifications.
As I said for me the real problem is in keeping support for older
Win32 versions which we probably lost if we do not make sth with it.
Well, if we step back and take a look at the bigger
picture, Win95/98/ME are a thing of the past, enough
to take a look at the Windows version usage charts.
So, unless we want to invest a huge amount of energy
into maintaining compatibility with this very old,
and unstable and rarely used systems, I think we should
rather just look forward and maybe even consider
dropping support for those, but at least no be blocked
by stuff which may break compatibility.
MSVC 2008 doesn't support Win95/98/ME at all. And
support is not full anymore for MSVC 2005 either.
Personally I'd also like to switch to UNICODE, which
also doesn't work with Win9x, yet it's a very good
feature.
All in all I don' see Win9x important enough to
invest much energy in it, or to rearrange Harbour
just to make Win95 happier.
WinCE is the contrary, as there seem to be some
buzz around it, and it's rather growing. So WinCE
may merit some more attention.
WinCE and Win95 are simply not of the same weight
these days.
In any case it'd be good to have a facility to exclude
packages for WinCE, even if those are 3rd party dependent
ones IMO.
But we do not need for this HB_ARCHOTC
?
[ I'd prefer to delete hbwhat from the repository BTW,
but that's another matter, it's a permanent candidate
for all sorts of problems and without developers actively
fixing/testing it. I haven't seen any user of it either,
so it pretty much looks like an unnecessary clog in
Harbour. ]
Maybe you should ask Andrzej about it? Maybe it can help.
AFAIK he was working extensively on this library in last
years but I do not know the current status of his code and
if he will want to public it.
Let's hope he shows up. It would be great to save
this lib. But f.e. last week I seem to have found
a very ugly bug, and no one bothered to even answer.
[ Some of these could probably be fixed to compile
under WinCE, but some definitely not. ]
Which one?
hbole, hbct, hbnf, hbsqlit3: yes
hbfbird, hbtpathy, hbodbc: maybe
gtwvg, hbwhat: I don't know.
hbole, hbct, hbnf, hbsqlit3, hbodbc, hbtpathy, hbwhat, gtwvg
are present in my MinGWCE builds. I do not have firebird installed
so I cannot check if it can be compiled and I do not know if WinCE
FB port exists. Even if not now then it can appear in the future.
Okay, so these could be fixed, but who will do this?
If so, we may just exclude these by HB_COMPILER.
HB_XBUILD is merely a signal that the current and
target platforms are different. Even Win64 build
creation on Win32 is a cross build. So for above purpose,
it's not suitable. HB_BUILD_WINCE I didn't know about
in GNU-make (and it seem to have a different meaning
in non-GNU make), but it doesn't seem like a std way
to control this problem to me.
Exactly and this should be the rule of HB_BUILD_WINCE.
Isn't it?
It's the reason why we have separate envvar. Single
HB_ARCHITECTURE is not enough.
Overall, current solution looks clumsy and
limited to me.
Yes, but this is a different problem. We should
probably have two separate variables for current
and target platform.
Like:
HB_COMPILER=pocc
HB_ARCHITECTURE=wince
HB_ARCH_HOST=win32 [we may allow leaving this empty for non-cross
builds]
HB_XBUILD => ( HB_ARCH_HOST != "" && HB_ARCH_HOST !=
HB_ARCHITECTURE )
Why not. But it's naming convention which we can clean. But still
the real problem I can see is with used API. For WinCE builds we have
HB_WINCE macro and it resolves the problem partially (we do not have
support for WinCE version) but we have nothing to keep Win9x/NT4
working.
and this is a problem for me.
I wanted to clean HB_WINCE to HB_OS_WIN_CE (and HB_OS_WIN_32 to
HB_OS_WIN), so in that picture HB_OS_WIN_95 and hb_OS_WIN_NT
could also fit.
But I'd be interested to see why do want to invest into
these directions.
BTW seeing libraries you listed as problematic in your WinCE builds it
looks that you will need HB_ARCHITECTURE=wince to exclude them from
WinCE builds when they can be build for WinCE and at least some of
them
like CT I intentionally updated to work with WinCE and even tested
some
functionality. So the problem is strictly bound with CRTL for WinCE
supported by given compiler not with HB_ARCHITECTURE. So if you really
want then you should exclude them using HB_COMPILER variable not
HB_ARCHITECTURE.
Yes, looks like it, see my above comment :)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
