Hi Juanjo,
On Sun, Jun 23, 2013 at 3:09 AM, Juan Jose Garcia-Ripoll <
juanjose.garciarip...@gmail.com> wrote:
>
> On Sat, Jun 22, 2013 at 10:41 AM, Dietrich Bollmann <
> dietr...@formgames.org> wrote:
>
>> Do I misunderstand the meaning of :WIN32?
>>
>
> This feature is related to the OS API that is used Win32 vs Mingw32 vs
> Cygwin32. On Windows64 the API used is still Win32, IIRC. I do not know how
> to change this without breaking some code out there, or whether the present
> situation is sensible or not. Maybe we coud at least push also Win64
>
Thanks! So I misunderstood the meaning of :win32 in the *features* list :)
The reason is that I try to integrate ECL with Rhino3d and the latter
complained about the compiler option 'WIN32' in combination with other
64bit options when compiling with 'asdf:make-build'. Also, when searching
for win32 on the internet, it is nearly always used in opposition to win64
and as compiler option. But as you wrote in your email, in a different
context it seems to be used as name for the windows API as well. What a
confusing and unfortunate choice for a naming scheme!
By the way, Rhino3D also complains when both, 'win32' and 'win64' are set.
This probably is caused by a similar confusion on their side. At least
when believing the notes on the page "Compiler Constants" setting both
seems to be the normal case (
http://msdn.microsoft.com/en-us/library/office/gg264614.aspx ; this page is
about the usage of these constants in visual basic but I suppose that it is
valuable for c++ as well):
> Because Win32 returns true in both 32-bit and 64-bit development
platforms it is important that the order within the #If...Then...#Else
directive returns the desired results in your code. For example, because
Win32 returns True in 64-bit (Win32is compatible in Win64 environments)
checking for Win32 before Win64 results in the Win64 condition never
running becauseWin32 returns True.
So maybe pushing win64 as well would be the right solution.
I wish Microsoft had made a less ambiguous choice, for example 'mswinapi'
together with '32bit' and '64bit'. But it seems that the current situation
results from historical reasons and that win32 can still be used in order
to make the porting of applications from 32 bit to 64 bit easier. Not sure
if not the opposite is the result though...
Thanks again, Dietrich
On Sun, Jun 23, 2013 at 3:09 AM, Juan Jose Garcia-Ripoll <
juanjose.garciarip...@gmail.com> wrote:
>
> On Sat, Jun 22, 2013 at 10:41 AM, Dietrich Bollmann <
> dietr...@formgames.org> wrote:
>
>> Do I misunderstand the meaning of :WIN32?
>> Is the build version still a 64 bit version and :WIN32 is added by error?
>> Is the variable ECL_WIN64 just ignored?
>>
>
> This feature is related to the OS API that is used Win32 vs Mingw32 vs
> Cygwin32. On Windows64 the API used is still Win32, IIRC. I do not know how
> to change this without breaking some code out there, or whether the present
> situation is sensible or not. Maybe we coud at least push also Win64
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
