Re: LibreSSL Windows port status update
The 32-bit windows support has been landed in the portable tree now for a few days now. Please try it out and report and/or fix any issues you find. I did a 64-bit build earlier today and there are a few bad pointer-long casts (long is size_t on win64), but nothing major that I saw. On Sun, Nov 30, 2014 at 9:58 PM, Brent Cook bust...@gmail.com wrote: I got a Windows 8.1 box running this weekend and spent some quality time making poll(2) emulation more robust, so that it can deal with more of the select-poll conversions in openssl(1) coming in the future. I also got the upstream poll conversion patches themselves in better working order. This Windows port is now achieved without any #ifdefs or odd workarounds. So, it should be possible to maintain support without having too many new warts in the LibreSSL tree. So, what can it do now? Well, you can run this command in a powershell window: .\apps\openssl.exe s_server -cert tests\server.pem and this in another: .\apps\openssl.exe s_client and type on the console back and forth interactively. You can also run this from powershell and still get the expected result: cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433 No big deal for those fancy 'everything works like a file' operating systems, but Windows very special in its handling of sockets vs. console IO vs pipes. Performance-wise, it's currently about 50x slower than Cygwin's native openssl.exe, but I have not begun to optimize anything yet. https://github.com/busterb/portable/commits/win32-minimal https://github.com/busterb/openbsd/commits/win32-minimal - Brent
Re: LibreSSL Windows port status update
On Mon, Dec 1, 2014 at 2:25 PM, Brad Smith b...@comstyle.com wrote: There is a URL posted at the bottom of that page that points out how it is broken and should not be used. I don't think we must distinguish the timeout errors and connection errors in the OpenSSL(1) tool, report ‘connection failed (or timeout)' is enough in such environment.
Re: LibreSSL Windows port status update
Not sure how much of an issue this would be, WSAPoll() is only available on Windows Vista and above. On Mon, 1 Dec 2014 14:10:44 +0800 Dongsheng Song dongsheng.s...@gmail.com wrote: Cool ! I can see you do lot's of update on select-poll conversions. The code become more and more complex since you want it works more general. Can we use simply WSAPoll[1] instead ? -- #ifdef _WIN32 #define poll WSAPoll #endif -- [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx On Mon, Dec 1, 2014 at 11:58 AM, Brent Cook bust...@gmail.com wrote: I got a Windows 8.1 box running this weekend and spent some quality time making poll(2) emulation more robust, so that it can deal with more of the select-poll conversions in openssl(1) coming in the future. I also got the upstream poll conversion patches themselves in better working order. This Windows port is now achieved without any #ifdefs or odd workarounds. So, it should be possible to maintain support without having too many new warts in the LibreSSL tree. So, what can it do now? Well, you can run this command in a powershell window: .\apps\openssl.exe s_server -cert tests\server.pem and this in another: .\apps\openssl.exe s_client and type on the console back and forth interactively. You can also run this from powershell and still get the expected result: cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433 No big deal for those fancy 'everything works like a file' operating systems, but Windows very special in its handling of sockets vs. console IO vs pipes. Performance-wise, it's currently about 50x slower than Cygwin's native openssl.exe, but I have not begun to optimize anything yet. https://github.com/busterb/portable/commits/win32-minimal https://github.com/busterb/openbsd/commits/win32-minimal - Brent
LibreSSL Windows port status update
I got a Windows 8.1 box running this weekend and spent some quality time making poll(2) emulation more robust, so that it can deal with more of the select-poll conversions in openssl(1) coming in the future. I also got the upstream poll conversion patches themselves in better working order. This Windows port is now achieved without any #ifdefs or odd workarounds. So, it should be possible to maintain support without having too many new warts in the LibreSSL tree. So, what can it do now? Well, you can run this command in a powershell window: .\apps\openssl.exe s_server -cert tests\server.pem and this in another: .\apps\openssl.exe s_client and type on the console back and forth interactively. You can also run this from powershell and still get the expected result: cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433 No big deal for those fancy 'everything works like a file' operating systems, but Windows very special in its handling of sockets vs. console IO vs pipes. Performance-wise, it's currently about 50x slower than Cygwin's native openssl.exe, but I have not begun to optimize anything yet. https://github.com/busterb/portable/commits/win32-minimal https://github.com/busterb/openbsd/commits/win32-minimal - Brent
Re: LibreSSL Windows port status update
Cool ! I can see you do lot's of update on select-poll conversions. The code become more and more complex since you want it works more general. Can we use simply WSAPoll[1] instead ? -- #ifdef _WIN32 #define poll WSAPoll #endif -- [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx On Mon, Dec 1, 2014 at 11:58 AM, Brent Cook bust...@gmail.com wrote: I got a Windows 8.1 box running this weekend and spent some quality time making poll(2) emulation more robust, so that it can deal with more of the select-poll conversions in openssl(1) coming in the future. I also got the upstream poll conversion patches themselves in better working order. This Windows port is now achieved without any #ifdefs or odd workarounds. So, it should be possible to maintain support without having too many new warts in the LibreSSL tree. So, what can it do now? Well, you can run this command in a powershell window: .\apps\openssl.exe s_server -cert tests\server.pem and this in another: .\apps\openssl.exe s_client and type on the console back and forth interactively. You can also run this from powershell and still get the expected result: cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433 No big deal for those fancy 'everything works like a file' operating systems, but Windows very special in its handling of sockets vs. console IO vs pipes. Performance-wise, it's currently about 50x slower than Cygwin's native openssl.exe, but I have not begun to optimize anything yet. https://github.com/busterb/portable/commits/win32-minimal https://github.com/busterb/openbsd/commits/win32-minimal - Brent
Re: LibreSSL Windows port status update
On 12/01/14 01:10, Dongsheng Song wrote: Cool ! I can see you do lot's of update on select-poll conversions. The code become more and more complex since you want it works more general. Can we use simply WSAPoll[1] instead ? -- #ifdef _WIN32 #define poll WSAPoll #endif -- [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx There is a URL posted at the bottom of that page that points out how it is broken and should not be used. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
