64-bit experiment

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

64-bit experiment

Cesar Strauss-2
Hello,

Following a recent thread on building a MinGW.org cross-compiler from
scratch, I became curious about seeing how far I could get by targeting
"x86_64-pc-mingw32" instead. After severely hacking at the MinGW.org
runtime and w32api, I finally got a 64-bit "hello world" executable
which runs on Wine and Windows 10. I neither looked nor used any code
from the mingw-w64 project. I did not try building a 64-bit DLL yet.

64-bit support in binutils and gcc was already there, thanks to Kai's
work upstream. For w32api, I used our gendef tool on the Windows 10
kernel32.dll and msvcrt.dll. For the runtime, I removed from the build
all files with 32-bit assembly code. Also, exported symbols now have a
different number of underscores. A few routines in the startup code had
to be removed to avoid crashes at runtime.

Going forward, we could begin to develop a proper 64-bit port of our
runtime and w32api. The first roadblock, I think, is the startup code.

Now, this brings the question: does our reservation against using the
w32api of the mingw-w64 project extends to their startup code? If not,
it would be much easier to simply merge back their runtime code.

Otherwise, we can proceed by trial and error. In that case, we can take
the opportunity to properly document the process for which we arrived at
the final result. If this does not work, we can later reconsider looking
at their startup code.

Regards,
Cesar

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

NightStrike
On Sun, Apr 2, 2017 at 3:47 PM, Cesar Strauss <[hidden email]> wrote:
> Hello,
[..]
> I neither looked nor used any code
> from the mingw-w64 project
[..]
> For w32api, I used our gendef tool on the Windows 10
> kernel32.dll and msvcrt.dll.

....*YOUR* gendef tool?  Earnie copied all of Kai's code and stuck it
in your repository, then changed all the licenses.  It's completely
stolen.

> Going forward, we could begin to develop a proper 64-bit port of our
> runtime and w32api.

....*PROPER* ?  There's nothing wrong with our port.

> Now, this brings the question: does our reservation against using the
> w32api of the mingw-w64 project extends to their startup code? If not,
> it would be much easier to simply merge back their runtime code.

Continuing Earnie's trend of stealing without credit?

> Otherwise, we can proceed by trial and error. In that case, we can take
> the opportunity to properly document the process for which we arrived at
> the final result.

...More insinuations that the mingw-w64 was not documented.  Sorry,
but it was.  So much so that it passed all of RedHat's legal team's
tests.

> If this does not work, we can later reconsider looking
> at their startup code.

Or maybe you should stop trying to steal like Earnie and instead try
to just work with us, like many other projects have done now (Fedora,
Wine, ReactOS, etc.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Cesar Strauss-2
Dear Nighstrike,

By your response, I see I have made a poor choice of words in a few
instances. I sincerely apologize. It was not truly my intention. Please
let me clarify.

On 04-02-2017 18:28, NightStrike wrote:
> On Sun, Apr 2, 2017 at 3:47 PM, Cesar Strauss <[hidden email]> wrote:
>> For w32api, I used our gendef tool on the Windows 10
>> kernel32.dll and msvcrt.dll.
>
> ....*YOUR* gendef tool?

Sorry, I did not meant to claim authorship of Kai's work.

What I meant was:

"For w32api, I used Kai's gendef tool, distributed by us (not the
mingw-w64 gendef, which is more recent), on the Windows 10 kernel32.dll
and msvcrt.dll"

>> Going forward, we could begin to develop a proper 64-bit port of our
>> runtime and w32api.
>
> ....*PROPER* ?  There's nothing wrong with our port.

Sorry, I didn't mean to imply the mingw-w64 port was not proper.

Let me rephrase:

"Going forward, we could begin to develop a proper 64-bit port of our
runtime and w32api, as opposed to my quick hack, which is not a proper
port by any means."

Sorry again for any confusion on my part. Thank you for calling
attention to these issues.

Best regards,

Cesar


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Earnie Boyd
In reply to this post by NightStrike
On 4/2/2017 5:28 PM, NightStrike wrote:

> On Sun, Apr 2, 2017 at 3:47 PM, Cesar Strauss <[hidden email]> wrote:
>> Hello,
> [..]
>> I neither looked nor used any code
>> from the mingw-w64 project
> [..]
>> For w32api, I used our gendef tool on the Windows 10
>> kernel32.dll and msvcrt.dll.
>
> ....*YOUR* gendef tool?  Earnie copied all of Kai's code and stuck it
> in your repository, then changed all the licenses.  It's completely
> stolen.
>

I don't remember changing licenses but the version I copied was a
different license than the one today.

>> Going forward, we could begin to develop a proper 64-bit port of our
>> runtime and w32api.
>
> ....*PROPER* ?  There's nothing wrong with our port.
>
>> Now, this brings the question: does our reservation against using the
>> w32api of the mingw-w64 project extends to their startup code? If not,
>> it would be much easier to simply merge back their runtime code.
>
> Continuing Earnie's trend of stealing without credit?
>

If there is missing credits that can be resolved.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Earnie Boyd
In reply to this post by Cesar Strauss-2
On 4/2/2017 3:47 PM, Cesar Strauss wrote:

> Hello,
>
> Following a recent thread on building a MinGW.org cross-compiler from
> scratch, I became curious about seeing how far I could get by targeting
> "x86_64-pc-mingw32" instead. After severely hacking at the MinGW.org
> runtime and w32api, I finally got a 64-bit "hello world" executable
> which runs on Wine and Windows 10. I neither looked nor used any code
> from the mingw-w64 project. I did not try building a 64-bit DLL yet.
>
> 64-bit support in binutils and gcc was already there, thanks to Kai's
> work upstream. For w32api, I used our gendef tool on the Windows 10
> kernel32.dll and msvcrt.dll. For the runtime, I removed from the build
> all files with 32-bit assembly code. Also, exported symbols now have a
> different number of underscores. A few routines in the startup code had
> to be removed to avoid crashes at runtime.
>
> Going forward, we could begin to develop a proper 64-bit port of our
> runtime and w32api. The first roadblock, I think, is the startup code.
>

Please go forward with your work.  Put it in the repository somewhere.

> Now, this brings the question: does our reservation against using the
> w32api of the mingw-w64 project extends to their startup code? If not,
> it would be much easier to simply merge back their runtime code.
>

I've been waiting on Keith to respond.  But

> Otherwise, we can proceed by trial and error. In that case, we can take
> the opportunity to properly document the process for which we arrived at
> the final result. If this does not work, we can later reconsider looking
> at their startup code.

This may be the better choice.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/04/17 14:52, Earnie wrote:
> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>> Following a recent thread on building a MinGW.org cross-compiler
>> from scratch, I became curious about seeing how far I could get by
>> targeting "x86_64-pc-mingw32" ...

What does this oxymoron mean?  32-bit code, for use on a 64-bit CPU?  
Why would I want that?  Or is it just an innately stupid choice of
name?  If the latter, *we* should avoid it; surely for preference it
should be "x86_64-pc-mingw64", (and "mingw64" should be adequate
shorthand).

>> ... instead. After severely hacking at the MinGW.org runtime and
>> w32api, I finally got a 64-bit "hello world" executable which runs
>> on Wine and Windows 10. I neither looked [at] nor used any code
>> from the mingw-w64 project.

Good.  Please keep it that way.

>> I did not try building a 64-bit DLL yet.
>>
>> 64-bit support in binutils and gcc was already there, thanks to
>> Kai's work upstream. For w32api, I used our gendef tool on the
>> Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed
>> from the build all files with 32-bit assembly code.

Ultimately, those will need to be converted, (or better still adapted
for multi-arch use); it may still need some work, but I added _some_
64-bit awareness in (e.g.) mingwex/math/log_generic.sx

>> Also, exported symbols now have a different number of underscores.

IIRC, the 32-bit compiler prefixes a single underscore to each public
symbol name, in generated assembly code, whereas 64-bit does not.  In
hand-crafted assembly code, the additional underscore must be added
by hand.

>> A few routines in the startup code had to be removed to avoid
>> crashes at runtime.

Can you enumerate them, please?

>> Going forward, we could begin to develop a proper 64-bit port of
>> our runtime and w32api.  The first roadblock, I think, is the
>> startup code.

Seems like a good place to start; we should conditionalize, to make
it as multi-arch as possible.

> Please go forward with your work.  Put it in the repository
> somewhere.

Maybe create a "branch" for 64-bit development?

>> Now, this brings the question: does our reservation against using
>> the w32api of the mingw-w64 project extends to their startup code?
>> If not, it would be much easier to simply merge back their runtime
>> code.
>
> I've been waiting on Keith to respond.

As I fully intended to do; it's just taken me a few days to acquire
a tuit of the appropriate form factor :)

>> Otherwise, we can proceed by trial and error. In that case, we can
>> take the opportunity to properly document the process for which we
>> arrived at the final result. If this does not work, we can later
>> reconsider looking at their startup code.
>
> This may be the better choice.

I agree; better to avoid the poisoned chalice.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJY585BAAoJEMCtNsY0flo/TZcP/2I307Ri46RpLjbw4Nn2kgRb
0Gd+7aKqFgOKcmV54FXy/TX+qnIeGnYlgm6cLzq96B2QBtSgg0xlpoa9NXjflVDT
jYj4WP/v2fVVZzwTjukMI9ZjuBWt/eYhKvjvjzXon0ciZ9/VmNt/jd1pr7/oH0wG
NLLsOOROZcw4pVy8iMBWjJ8jbpYhgegsYtEqMBY1QOaG9sO2EplwD7j3NExHqHfA
G4vNDBIAO+0opv7tJQLC+7ioFd5uPEUMX67VwYOVFeJaRlG6nDpAafF54WYKI0mQ
ye9pJUUr+yVGofs0IBN0juYCKJpdtDFBZAwPdXdVdD8UjE6tWwlJ5MzC1e/VbBJz
LmQd11RPUFZNia150rjGeGpacxaVYJyZ/ZzUPXhm/UUTjgYwtW+PzMUPDsJbXbTG
vJYQisNhmGnp6pWh1brRo+oG7ANR9jOMQdYYDcNO/g2Ka5NwEjFfbAQeEGvm43D7
MzJm1M+pgtsm0Phv+1BXtReTDqAzxsun5WZbAXyBmEPB8HiXTm8tGcUTglofiMbO
MrTqSFDFn/2uPGiMOJGcwKQktSg/D9cfEaTxQVnUbxUVUUaP2LqouMo+PjHB1lsd
9RcWhbBDAOl+SguNRtkA1o5gQgeepKHzRd0lhtHVHuaR2w8YkKndCtQdRb1vJ2PP
pXGw3WvWNsDL5NqlmNre
=Fsfm
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

David Gressett-5

>From: Keith Marshall <[hidden email]>


>On 07/04/17 14:52, Earnie wrote:
>> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>>> Following a recent thread on building a MinGW.org cross-compiler
>>> from scratch, I became curious about seeing how far I could get by
>>> targeting "x86_64-pc-mingw32" ...
... snip ...
>>> Otherwise, we can proceed by trial and error. In that case, we can
>>> take the opportunity to properly document the process for which we
>>> arrived at the final result. If this does not work, we can later
>>> reconsider looking at their startup code.
>>
>>> This may be the better choice.

>I agree; better to avoid the poisoned chalice.

>- --
>Regards,
>Keith.

I am in full agreement with Keith on this. Some years ago, I was
employed as IT support in a law office where I developed software to
automate the creation of the paperwork involved in filing lawsuits, i.e,
I was generating ingredients for poisoned chalices, and I know far
more than most people know about why they should be avoided.

As I have mentioned in previous messages to this list, I think
that the best long-term solution to navigating the Microsoft
legal minefield is to contact Microsoft and get a detailed answer as
what is permissible and what is not. The official Microsoft
philosophy about open-source software has improved
substantially in recent years, and it may even be possible
to get permission to access some license-protected
information that would otherwise be inaccessible.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Cesar Strauss-2
In reply to this post by Keith Marshall-3
On 07-04-2017 14:37, Keith Marshall wrote:

> On 07/04/17 14:52, Earnie wrote:
>> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>>> Following a recent thread on building a MinGW.org cross-compiler
>>> from scratch, I became curious about seeing how far I could get by
>>> targeting "x86_64-pc-mingw32" ...
>
> What does this oxymoron mean?  32-bit code, for use on a 64-bit CPU?  
> Why would I want that?  Or is it just an innately stupid choice of
> name?  If the latter, *we* should avoid it; surely for preference it
> should be "x86_64-pc-mingw64", (and "mingw64" should be adequate
> shorthand).
>

OK.

>>> A few routines in the startup code had to be removed to avoid
>>> crashes at runtime.
>
> Can you enumerate them, please?

Sure. They are:

void _mingw32_init_fmode (void);
void _pei386_runtime_relocator (void);
void __main();

Also, there is a weird crash when the startup calls "main", which can be
avoided by calling "rmain" instead.

It would be nice to be able to use the 64-bit GDB from the mingw-w64
project to step into code, but I'll try to avoid it for now.

>> Please go forward with your work.  Put it in the repository
>> somewhere.
>
> Maybe create a "branch" for 64-bit development?

OK. I'll put my experiment code there to gain visibility. We can clean
up the patches later in a new branch, suitable for merging, if we decide
to do so.

>>> Otherwise, we can proceed by trial and error. In that case, we can
>>> take the opportunity to properly document the process for which we
>>> arrived at the final result. If this does not work, we can later
>>> reconsider looking at their startup code.
>
>> This may be the better choice.
>
> I agree; better to avoid the poisoned chalice.

OK.

Regards,
Cesar

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Earnie Boyd
In reply to this post by Keith Marshall-3


On 4/7/2017 1:37 PM, Keith Marshall wrote:

> On 07/04/17 14:52, Earnie wrote:
>> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>>> Following a recent thread on building a MinGW.org cross-compiler
>>> from scratch, I became curious about seeing how far I could get by
>>> targeting "x86_64-pc-mingw32" ...
>
> What does this oxymoron mean?  32-bit code, for use on a 64-bit CPU?  
> Why would I want that?  Or is it just an innately stupid choice of
> name?  If the latter, *we* should avoid it; surely for preference it
> should be "x86_64-pc-mingw64", (and "mingw64" should be adequate
> shorthand).
>

-mingw64 already exists as a choice in config.guess and config.sub.

>>> ... instead. After severely hacking at the MinGW.org runtime and
>>> w32api, I finally got a 64-bit "hello world" executable which runs
>>> on Wine and Windows 10. I neither looked [at] nor used any code
>>> from the mingw-w64 project.
>
> Good.  Please keep it that way.
>
>>> I did not try building a 64-bit DLL yet.
>>>
>>> 64-bit support in binutils and gcc was already there, thanks to
>>> Kai's work upstream. For w32api, I used our gendef tool on the
>>> Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed
>>> from the build all files with 32-bit assembly code.
>
> Ultimately, those will need to be converted, (or better still adapted
> for multi-arch use); it may still need some work, but I added _some_
> 64-bit awareness in (e.g.) mingwex/math/log_generic.sx
>
>>> Also, exported symbols now have a different number of underscores.
>
> IIRC, the 32-bit compiler prefixes a single underscore to each public
> symbol name, in generated assembly code, whereas 64-bit does not.  In
> hand-crafted assembly code, the additional underscore must be added
> by hand.
>

The 64bit references also do not carry the @# suffix to indicate the
argument bytes.

>>> A few routines in the startup code had to be removed to avoid
>>> crashes at runtime.
>
> Can you enumerate them, please?
>
>>> Going forward, we could begin to develop a proper 64-bit port of
>>> our runtime and w32api.  The first roadblock, I think, is the
>>> startup code.
>
> Seems like a good place to start; we should conditionalize, to make
> it as multi-arch as possible.
>

IIRC _win64 is defined as well as _win32 by the compiler.  The absence
of _win64 is what can be used to indicate 32bit versus 64bit.

>> Please go forward with your work.  Put it in the repository
>> somewhere.
>
> Maybe create a "branch" for 64-bit development?
>

That was my thought.

>>> Now, this brings the question: does our reservation against using
>>> the w32api of the mingw-w64 project extends to their startup code?
>>> If not, it would be much easier to simply merge back their runtime
>>> code.
>
>> I've been waiting on Keith to respond.
>
> As I fully intended to do; it's just taken me a few days to acquire
> a tuit of the appropriate form factor :)
>

I knew that, just took longer than _I_ wanted. :D

>>> Otherwise, we can proceed by trial and error. In that case, we can
>>> take the opportunity to properly document the process for which we
>>> arrived at the final result. If this does not work, we can later
>>> reconsider looking at their startup code.
>
>> This may be the better choice.
>
> I agree; better to avoid the poisoned chalice.

Yes.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Earnie Boyd
In reply to this post by Cesar Strauss-2
On 4/7/2017 5:57 PM, Cesar Strauss wrote:

>
> It would be nice to be able to use the 64-bit GDB from the mingw-w64
> project to step into code, but I'll try to avoid it for now.
>

Maybe use the Cygwin64 gdb instead?

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Earnie Boyd
In reply to this post by David Gressett-5
On 4/7/2017 3:55 PM, David Gressett wrote:

>
>> From: Keith Marshall <[hidden email]>
>
>
>> On 07/04/17 14:52, Earnie wrote:
>>> On 4/2/2017 3:47 PM, Cesar Strauss wrote:
>>>> Following a recent thread on building a MinGW.org cross-compiler
>>>> from scratch, I became curious about seeing how far I could get by
>>>> targeting "x86_64-pc-mingw32" ...
> ... snip ...
>>>> Otherwise, we can proceed by trial and error. In that case, we can
>>>> take the opportunity to properly document the process for which we
>>>> arrived at the final result. If this does not work, we can later
>>>> reconsider looking at their startup code.
>>>
>>>> This may be the better choice.
>
>> I agree; better to avoid the poisoned chalice.
>
> I am in full agreement with Keith on this. Some years ago, I was
> employed as IT support in a law office where I developed software to
> automate the creation of the paperwork involved in filing lawsuits, i.e,
> I was generating ingredients for poisoned chalices, and I know far
> more than most people know about why they should be avoided.
>

We would use SPI lawyers to defend our position and counter with the
fact that the chalice is using our trademarked name.  I do not intend to
rebut this so please do not flame.  I'm only stating fact to an already
tender position.

> As I have mentioned in previous messages to this list, I think
> that the best long-term solution to navigating the Microsoft
> legal minefield is to contact Microsoft and get a detailed answer as
> what is permissible and what is not. The official Microsoft
> philosophy about open-source software has improved
> substantially in recent years, and it may even be possible
> to get permission to access some license-protected
> information that would otherwise be inaccessible.
>

Especially since they've been openly helping Cygwin including to the
point of adding to the API to support them (and themselves) with a POSIX
image.  There have been several improvements to the API to help support
the Cygwin product.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 64-bit experiment

Keith Marshall-3
In reply to this post by Earnie Boyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/04/17 17:32, Earnie wrote:
>>>> Going forward, we could begin to develop a proper 64-bit port of
>>>> our runtime and w32api.  The first roadblock, I think, is the
>>>> startup code.
>>
>> Seems like a good place to start; we should conditionalize, to make
>> it as multi-arch as possible.
>
> IIRC _win64 is defined as well as _win32 by the compiler.  The absence
> of _win64 is what can be used to indicate 32bit versus 64bit.

More or less.  AFAIK, the two macros are actually _WIN32 and _WIN64,
(upper case matters), and *both* are defined by the 64-bit compiler;
the 32-bit compiler defines only _WIN32.  Thus, the structure for the
conditionals becomes:

  #if defined _WIN64
  /* 64-bit specific code here:
   */
   .
   .
  #elif defined _WIN32 /* or maybe just #else */
  /* 32-bit specific code here:
   */
   .
   .
  #endif

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJY6RazAAoJEMCtNsY0flo/umcP/29X4f2R6FP7vm/VL0V6m9pw
FiN3CVQ2TGOHJkt2McCW8td/suAsV2vPSFpcynS6xKWjHPB9c3JWcfHYMtk0HXWe
hpLA7c1EyhrpdzHfC5+4F392ZRBmalFiYOXTYg3ucUzfOwO7HeDBGgKhw9Y5pq42
AQ4ZQ2VL6W5TUYYkO76lVRvbU7+1dflINEpPDaMWRjy62shMV+3gG1Z8amVt6B4I
RI7Up/8VgNrcxzSrfSf5C+ZPlChR1OyeujCgWPPB9yp5KzO0YDdCAP0aH1Cw2wrt
Qv6XuqccrRHs5lY5bmd/7QDZ0kGhHXAqnC3aRtH6pXxH7TwZpsDTK+TJBGHU0iF1
kf3J6PzjW+tWauYeQhPSlLoVMtrrOJdy26KxJANO/SaN1b4qkCHhQV4CR9RWvkDm
xynB8NcTdK52AW5HpsJIqQfNnSwaYksu/KnpJRF8yoXKmKFtWtYhFVHhOeU1TSNO
+LBe7DErPRWHetqAb5UhUe+LYVy4UZINSkBitW0iMeSdMLS8I98QY1pl7K5CZUaH
lbyMyWEUFX4Y/pcv5zW7TgyBZDbJh2A5w+JMnIjwBb9TEVaNmvju527SI4DcDdZr
ShsO9s5kkSlZvRaKJ0Pf+08miVtUcvp0Ye3S3tvEBCrXKUh323xM9vBEF3ygKgWJ
Oi9dGi4I/trwbF/BlwRX
=WvnO
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...