That sounds good. What do you think Christof? Do you think it would alter any of the default behavior? I have to run so I can't look into this more until later today.
it's easy: AI_ALL and AI_V4MAPPED are only available since Windows Vista.
the default settings compile for Windows2000 (or so).
to compile for windows vista (and aboce), use the following macros (preferably in the Makefile):
-DWINVER=0x0600 -D_WIN32_WINNT=0x0600
(this is already done in the autotools-Makefile; but afaik not in the src/makefile.mingw)
alternatively (and probably additionally), the use of these macros should probably be protected by ifdef clauses.
in iemnet (which has backported some of the new code from s_net.c) i use:
hints.ai_flags |= AI_PASSIVE #ifdef AI_ALL | AI_ALL /* both IPv4 and IPv6 addrs */ #endif #ifdef AI_V4MAPPED | AI_V4MAPPED /* fallback to IPv4-mapped IPv6 addrs */ #endif | 0;
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
@Miller: are you compiling on a Windows XP machine !?
The #ifdefs would fix the compilation error on Windows XP, but we still have to compile the release on a Windows Vista+ machine to make the IPv6 functionality available. I think Windows XP doesn't even support IPv6 before service pack 3.
IMO, we should finally raise the default WINVER to Windows Vista, at least. Windows XP is *ancient* by now. Recently, even support for Windows 7 has ended...
On macOS, the minimum supported version is 10.6, which is from 2009. Windows XP was first released in 2001...
We might still allow people to compile for Windows XP by overriding WINVER, but it shouldn't be the default anymore.
Christof
On 28.05.2020 13:06, Dan Wilcox wrote:
That sounds good. What do you think Christof? Do you think it would alter any of the default behavior? I have to run so I can't look into this more until later today.
it's easy: AI_ALL and AI_V4MAPPED are only available since Windows Vista.
the default settings compile for Windows2000 (or so).
to compile for windows vista (and aboce), use the following macros (preferably in the Makefile):
-DWINVER=0x0600 -D_WIN32_WINNT=0x0600
(this is already done in the autotools-Makefile; but afaik not in the src/makefile.mingw)
alternatively (and probably additionally), the use of these macros should probably be protected by ifdef clauses.
in iemnet (which has backported some of the new code from s_net.c) i use:
 hints.ai_flags |= AI_PASSIVE #ifdef AI_ALL    | AI_ALL     /* both IPv4 and IPv6 addrs */ #endif #ifdef AI_V4MAPPED    | AI_V4MAPPED /* fallback to IPv4-mapped IPv6 addrs */ #endif    | 0;
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I'm cross-compiling on linux and testing on WinXP, which is the newest version I have.
It sounds like I should put out a WinXP version (using Iohannes's #ifdef style) and another with IPv6 turned on for Vista+.
I'm not sure but I get the impression lots of folks are using WinXP - I hear it described as the "last good version" from time to time. I have to agree personally, fwiw...
cheers M
On Thu, May 28, 2020 at 01:49:58PM +0200, Christof Ressi wrote:
@Miller: are you compiling on a Windows XP machine !?
The #ifdefs would fix the compilation error on Windows XP, but we still have to compile the release on a Windows Vista+ machine to make the IPv6 functionality available. I think Windows XP doesn't even support IPv6 before service pack 3.
IMO, we should finally raise the default WINVER to Windows Vista, at least. Windows XP is *ancient* by now. Recently, even support for Windows 7 has ended...
On macOS, the minimum supported version is 10.6, which is from 2009. Windows XP was first released in 2001...
We might still allow people to compile for Windows XP by overriding WINVER, but it shouldn't be the default anymore.
Christof
On 28.05.2020 13:06, Dan Wilcox wrote:
That sounds good. What do you think Christof? Do you think it would alter any of the default behavior? I have to run so I can't look into this more until later today.
it's easy: AI_ALL and AI_V4MAPPED are only available since Windows Vista.
the default settings compile for Windows2000 (or so).
to compile for windows vista (and aboce), use the following macros (preferably in the Makefile):
-DWINVER=0x0600 -D_WIN32_WINNT=0x0600
(this is already done in the autotools-Makefile; but afaik not in the src/makefile.mingw)
alternatively (and probably additionally), the use of these macros should probably be protected by ifdef clauses.
in iemnet (which has backported some of the new code from s_net.c) i use:
?hints.ai_flags |= AI_PASSIVE #ifdef AI_ALL ???| AI_ALL ????/* both IPv4 and IPv6 addrs */ #endif #ifdef AI_V4MAPPED ???| AI_V4MAPPED /* fallback to IPv4-mapped IPv6 addrs */ #endif ???| 0;
Dan Wilcox @danomatika <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!VQWHE8c... > danomatika.com <https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!VQWHE8cZfk0pAJR... > robotcowboy.com <https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!VQWHE8cZfk0pAJ... >
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
which is the newest version I have.
You might want to consider an upgrade ;-)
I'm not sure but I get the impression lots of folks are using WinXP - I hear it described as the "last good version" from time to time.
Nah, I think Windows 7 holds that position. And people will probably say that about Windows 10 in 20 years...
IMO, no one should use Windows XP in 2020 unless they absolutely have to (e.g. they can't upgrade). It's just too outdated.
It sounds like I should put out a WinXP version (using Iohannes's #ifdef style) and another with IPv6 turned on for Vista+.
That could be a solution. After all, you still ship a OSX PPC version :-)
Christof
On 28.05.2020 15:56, Miller Puckette wrote:
I'm cross-compiling on linux and testing on WinXP, which is the newest version I have.
It sounds like I should put out a WinXP version (using Iohannes's #ifdef style) and another with IPv6 turned on for Vista+.
I'm not sure but I get the impression lots of folks are using WinXP - I hear it described as the "last good version" from time to time. I have to agree personally, fwiw...
cheers M
On Thu, May 28, 2020 at 01:49:58PM +0200, Christof Ressi wrote:
@Miller: are you compiling on a Windows XP machine !?
The #ifdefs would fix the compilation error on Windows XP, but we still have to compile the release on a Windows Vista+ machine to make the IPv6 functionality available. I think Windows XP doesn't even support IPv6 before service pack 3.
IMO, we should finally raise the default WINVER to Windows Vista, at least. Windows XP is *ancient* by now. Recently, even support for Windows 7 has ended...
On macOS, the minimum supported version is 10.6, which is from 2009. Windows XP was first released in 2001...
We might still allow people to compile for Windows XP by overriding WINVER, but it shouldn't be the default anymore.
Christof
On 28.05.2020 13:06, Dan Wilcox wrote:
That sounds good. What do you think Christof? Do you think it would alter any of the default behavior? I have to run so I can't look into this more until later today.
it's easy: AI_ALL and AI_V4MAPPED are only available since Windows Vista.
the default settings compile for Windows2000 (or so).
to compile for windows vista (and aboce), use the following macros (preferably in the Makefile):
-DWINVER=0x0600 -D_WIN32_WINNT=0x0600
(this is already done in the autotools-Makefile; but afaik not in the src/makefile.mingw)
alternatively (and probably additionally), the use of these macros should probably be protected by ifdef clauses.
in iemnet (which has backported some of the new code from s_net.c) i use:
?hints.ai_flags |= AI_PASSIVE #ifdef AI_ALL ???| AI_ALL ????/* both IPv4 and IPv6 addrs */ #endif #ifdef AI_V4MAPPED ???| AI_V4MAPPED /* fallback to IPv4-mapped IPv6 addrs */ #endif ???| 0;
Dan Wilcox @danomatika <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!VQWHE8c... > danomatika.com <https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!VQWHE8cZfk0pAJR... > robotcowboy.com <https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!VQWHE8cZfk0pAJ... >
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
On 5/28/20 4:37 PM, Christof Ressi wrote:
which is the newest version I have.
You might want to consider an upgrade ;-)
note that the cross-compilers compile newer versions of Windows just fine. they just have a very conservative default setting.
gfamdsr IOhannes
This will sound precious, but I have a policy of pushing back against the forced-upgrade pratcices of Microsoft and Apple. I suspect many people outside of Europe/North America are using very old machines.
At any rate, I now plan to put out a 64-bit test version compiled with IPV6 support (-DWINVER=0x0600 -D_WIN32_WINNT=0x0600 as Iohannes suggests), and later go back and provide XP versions in 64 and 32 bits.
Thanks for the very quick responses!
Miller
On Thu, May 28, 2020 at 04:57:54PM +0200, IOhannes m zm??lnig wrote:
On 5/28/20 4:37 PM, Christof Ressi wrote:
which is the newest version I have.
You might want to consider an upgrade ;-)
note that the cross-compilers compile newer versions of Windows just fine. they just have a very conservative default setting.
gfamdsr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Thu, May 28, 2020 at 11:36 AM Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
This will sound precious, but I have a policy of pushing back against the forced-upgrade pratcices of Microsoft and Apple. I suspect many people outside of Europe/North America are using very old machines.
At any rate, I now plan to put out a 64-bit test version compiled with IPV6 support (-DWINVER=0x0600 -D_WIN32_WINNT=0x0600 as Iohannes suggests), and later go back and provide XP versions in 64 and 32 bits.
Is there any way for a user to know if their version of Pd is 32 or 64 bit while it's running? Attempting to load externals of the wrong type just gives those vague 'unable to load' errors. If the 'About PD' window would say which address size it uses that could help. (I use different versions on a few different machines and I can't remember which is which) Help->About Pd gives: "Pd version 0.50.0", maybe it could say "Pd version 0.50.0 (64-bit addressing)".
Martin
Let's start a new thread for this.
Attempting to load externals of the wrong type just gives those vague 'unable to load' errors.
I have some cross-platform CPU architecture detection code which I code port to Pd, so that we could have more descriptive error messages.
Help->About Pd gives: "Pd version 0.50.0", maybe it could say "Pd version 0.50.0 (64-bit addressing)".
IMO, it doesn't really fix the undescriptive error messages, because the user has to know in advance that the problem is about 64 bit/32 bit, before they even look for that info. Also, they don't always know at first glance if the externals are 64-bit or 32-bit...
I'd still like to see "Pd version 0.50.0 (64-bit)", though.
Christof
On 28.05.2020 17:59, Martin Peach wrote:
On Thu, May 28, 2020 at 11:36 AM Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
This will sound precious, but I have a policy of pushing back against the forced-upgrade pratcices of Microsoft and Apple. I suspect many people outside of Europe/North America are using very old machines.
At any rate, I now plan to put out a 64-bit test version compiled with IPV6 support (-DWINVER=0x0600 -D_WIN32_WINNT=0x0600 as Iohannes suggests), and later go back and provide XP versions in 64 and 32 bits.
Is there any way for a user to know if their version of Pd is 32 or 64 bit while it's running? Attempting to load externals of the wrong type just gives those vague 'unable to load' errors. If the 'About PD' window would say which address size it uses that could help. (I use different versions on a few different machines and I can't remember which is which) Help->About Pd gives: "Pd version 0.50.0", maybe it could say "Pd version 0.50.0 (64-bit addressing)".
Martin
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
to answer martin's question: deken will print platform information at startup time, albeit the printout is only visible if you raise the verbosity in the Pd-console.
something like:
[deken] Platform detected: Linux-x86_64-float32 [deken] Platform re-detected: Linux-amd64-float32
this is basically the information you asked for, with a few caveats: - if you clear the Pd-console, the printouts are gone. - there's some naming inconsistency (e.g. in the example above you see both "amd64" and "x86_64" which is really the same. - it might be confusing to see *two* lines with essentially the same information.
the first line is the result of an architecture detection on the GUI-side. however, the GUI might have a *different* architecture than the Pd-core (and the latter matters when it comes to loading externals). therefore the Pd-core sends its architecture to the GUI as well, triggering the 2nd output.
i guess the printout could be improved, i'm open to suggestions.
On 5/28/20 7:22 PM, Christof Ressi wrote:
I have some cross-platform CPU architecture detection code which I code port to Pd, so that we could have more descriptive error messages.
hmm, i don't think *that* is the problem here. it's quite clear which binaries Pd can load at compile time (as is reported by the 2nd line in the deken initialisation; see above)
but i think your idea is to improve the error message along the lines of:
failed to load foo.dll (the library is 32bit, but Pd is a 64bit process)
the trivial part is the 2nd one ("this Pd is 64bit"). the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
the deken cmdline utility can do this, but it utilizes several specialized libraries for the task. i think embedding such libraries into Pd would be an overkill for the problem.
mgasf IOhannes
the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
Yes, but I already have the code (I wrote it for [vstplugin~]). It's ~300 lines of C++, I just have to port it to C.
https://git.iem.at/pd/vstplugin/-/blob/master/vst/Plugin.cpp#L352
It maybe overkill, though. Dunno...
Christof
On 28.05.2020 20:53, IOhannes m zmölnig wrote:
to answer martin's question: deken will print platform information at startup time, albeit the printout is only visible if you raise the verbosity in the Pd-console.
something like:
[deken] Platform detected: Linux-x86_64-float32 [deken] Platform re-detected: Linux-amd64-float32
this is basically the information you asked for, with a few caveats:
- if you clear the Pd-console, the printouts are gone.
- there's some naming inconsistency (e.g. in the example above you see
both "amd64" and "x86_64" which is really the same.
- it might be confusing to see *two* lines with essentially the same
information.
the first line is the result of an architecture detection on the GUI-side. however, the GUI might have a *different* architecture than the Pd-core (and the latter matters when it comes to loading externals). therefore the Pd-core sends its architecture to the GUI as well, triggering the 2nd output.
i guess the printout could be improved, i'm open to suggestions.
On 5/28/20 7:22 PM, Christof Ressi wrote:
I have some cross-platform CPU architecture detection code which I code port to Pd, so that we could have more descriptive error messages.
hmm, i don't think *that* is the problem here. it's quite clear which binaries Pd can load at compile time (as is reported by the 2nd line in the deken initialisation; see above)
but i think your idea is to improve the error message along the lines of:
failed to load foo.dll (the library is 32bit, but Pd is a 64bit process)
the trivial part is the 2nd one ("this Pd is 64bit"). the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
the deken cmdline utility can do this, but it utilizes several specialized libraries for the task. i think embedding such libraries into Pd would be an overkill for the problem.
mgasf IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Thu, May 28, 2020 at 2:53 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
Perhaps getLastError() or errno would give a clue after the calls to dlopen()/LoadLibrary() fail, without needing to inspect the file. Usually there are a few different errors possible.
Martin
We already use getLastError() / errno... The error code/message is not specific enough.
Again, I already have the necessary architecture detection code, and if people don't consider it overkill, I could try to integrate it into Pd.
Christof
On 28.05.2020 21:48, Martin Peach wrote:
On Thu, May 28, 2020 at 2:53 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
Perhaps getLastError() or errno would give a clue after the calls to dlopen()/LoadLibrary() fail, without needing to inspect the file. Usually there are a few different errors possible.
Martin
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 5/28/20 1:49 PM, Christof Ressi wrote:
@Miller: are you compiling on a Windows XP machine !?
no. he is cross-compiling.
on my system (Debian/sid, Mingw-7.0.0, gcc:9.3-win32), i had the same problem (that's why i had the answer ready):
compiling the following source with the cross-compiler:
~~~ #include <stdio.h> int main() { #ifdef WINVER printf("WINVER=0x%X\n", WINVER); #endif #ifdef _WIN32_WINNT printf("_WIN32_WINNT=0x%X\n", _WIN32_WINNT); #endif return 0; } ~~~
prints: _WIN32_WINNT=0x502
(for both i686 and x86_64)
The #ifdefs would fix the compilation error on Windows XP, but we still have to compile the release on a Windows Vista+ machine to make the IPv6
that's why i proposed *both* fixes (the ifdefs and raising the WINVER)
On macOS, the minimum supported version is 10.6, which is from 2009. Windows XP was first released in 2001...
although i think that these days more people are using XP than OSX-10.6
We might still allow people to compile for Windows XP by overriding WINVER, but it shouldn't be the default anymore.
+1.
there should be a configure option to select the WINVER from the cmdline.
gadsr IOhannes
-
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig -
Martin Peach -
Miller Puckette