On Dec 4, 2007, at 3:12 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Why add something different if _WIN32 already exists and is automatically defined by all the compilers we use?
to not have to change code throughout everything?
i totally agree that one should rather use _WIN32 than MSW (or whatever), that is why i have been using it in my code for years.
btw, there seems to be some obfuscation with the _WIN32, since i have seen _a lot_ of projects that perfectly well use "__linux__" but fail to use "_WIN32". these projects are not limited to w32- ports of linux code. it is probably because _WIN32 is one of the worst documented automagic macros... so it is not only pd-code that uses hacks to find out whether it is actually compiled for w32.
furthermore, having _WIN32 defined on w64 is an _ugly_ hack on micro $oft's side, there is no need to support that. MSW (if it is kept) could/should be defined for both w32 and w64, and it should be automatically defined (that is: not within the makefile but within a central place, like m_pd.h)
There is lots of Windows stuff that is ugly hacks, I don't think it is wise in the long run to pick and choose which ones to support and not. The best plan on all platforms is to follow the standard guidelines for how to do such things. That way there is a large, existing body of people who know about them, those methods are documented, etc. Doing custom things means it's undocumented and basically only one or two people know about them.
AFAIK, that means using _WIN32, that means using the registry.
.hc
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie