Hi Viktor,
[ Sorry for my bad English :'( ]
I don't see any need for a make-level solution. All macros can
be defined from source. Why is it better to define them on
make level?
Because if someone tries to compile Harbour with a version of SDK not
supported, he don't have compile-time error.
If in the example of my previous thread post I protect IP_ADAPTER_ADDRESSES use
with .-
#if _WIN32_WINNT >= 0x0501
...
#endif
And the macro _WIN32_WINNT is passed to my code, the code can be compiled with an SDK of 0x0500 and the binary can run on any
version, just don't have this functionality in earlier versions.
Please note that the same thing happens with the basic functionality of
ws2_32.dll if we don't implement an alternative.
So the use of dynamic calls is only justified for functions with alternative because if there is no alternative simply does not
have this functionality in earlier versions, IMHO.
Best regards,
--
Xavi
El 28/02/2010 19:09, Viktor Szakáts escribió:
NTDDI_VERSION = maximum OS version supported by SDK/Windows-headers
_WIN32_WINNT = OS version we want to target
Okay, but if you remember my thread starting post .-
"
IMHO the best solution is to define the version of Windows that supports the
C compiler before compilation.
For example, if your C compiler supports Vista: set
HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600
http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx
Some structures are defined only in the headers from one version of Windows
other may change.
IPv6 is supported from Windows Server 2003, Windows XP.
Even calling functions dynamically is necessary data with which they work.
It can make the binary work with earlier versions but the headers and the
code should be protected by .-
#if _WIN32_WINNT>= 0x0501
...
#endif
If not, we can have compile-time errors.
Please, what do you think about this, comments?
"
And we *force* _WIN32_WINNT or NTDDI_VERSION in hard code.
If someone compiles Harbour with earlier versions of C compiler headers may
have compile-time errors.
IMHO we need a solution in to make-system and I'm not an expert on this.
Sorry but I don't understand this thread anymore.
IMO the solution is simple: If you need to use Windows API
features which are not supported in all Windows versions:
1) make it using dynamic calls, so binary won't break if feature not available
2) detect OS header version (only this may need compiler specific solutions)
3) force target OS version by defining _WIN32_WINNT before windows.h,
if target OS version is known to be supported by headers
If only constants are missing you can replace 2) + 3) with
simple manual definition of those missing constants.
I don't see any need for a make-level solution. All macros can
be defined from source. Why is it better to define them on
make level?
Besides it's quite difficult to discuss this without knowing what do
you exactly want to make here. Maybe you could post some code
(patch) to see where you're standing at ATM.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
