http://bugs.winehq.org/show_bug.cgi?id=30815
Bug #: 30815 Summary: Can't create winsock on Proteus ISIS for remote controll through mplabX Product: Wine Version: 1.5.5 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock AssignedTo: wine-bugs@winehq.org ReportedBy: diecore64@gmail.com Classification: Unclassified
On Proteus ISIS 7.10 as also older versions when i try to enable the remote debug monitor from debug menu to make a tcp listening connection so i can remote control the ISIS through mplabX it shows this on the terminal:
fixme:winsock:convert_socktype_w2u unhandled Windows socket type 0
http://bugs.winehq.org/show_bug.cgi?id=30815
DieCore diecore64@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diecore64@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #1 from DieCore diecore64@gmail.com 2012-05-31 16:52:48 CDT --- Also ISIS shows a popup which its says: VDM server failed to create socket
http://bugs.winehq.org/show_bug.cgi?id=30815
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com 2012-05-31 17:17:09 CDT --- Please attach a +winsock log. Is this program available for free download? If yes please tell the steps to reproduce.
http://bugs.winehq.org/show_bug.cgi?id=30815
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Status|UNCONFIRMED |NEW URL| |http://www.labcenter.com/do | |wnload/prodemo_download.cfm CC| |dank@kegel.com Ever Confirmed|0 |1
--- Comment #3 from Dan Kegel dank@kegel.com 2012-05-31 23:06:03 CDT --- Reproducible with the free demo, 49c2d7644db31e8b4ce0c81fae738c13419675ce prodemo.exe
Here's +winsock,+relay of BIN\ISIS.EXE with wine-1.5.4 when turning on the "remote debug monitor" as the OP described:
0024:Call ws2_32.WSAStartup(00000002,0089f554) ret=004b8e4e trace:winsock:WSAStartup verReq=2 trace:winsock:WSAStartup succeeded 0024:Ret ws2_32.WSAStartup() retval=00000000 ret=004b8e4e 0024:Call ws2_32.socket(00000002,00000000,00000000) ret=004b8e6e trace:winsock:WS_socket af=2 type=0 protocol=0 trace:winsock:WSASocketA af=2 type=0 protocol=0 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW af=2 type=0 protocol=0 protocol_info=(nil) group=0 flags=0x1 fixme:winsock:convert_socktype_w2u unhandled Windows socket type 0 warn:winsock:WSASocketW failed! 0024:Ret ws2_32.socket() retval=ffffffff ret=004b8e6e
MSDN says "To preserve backward compatibility, the Ws2_32.dll treats the value of zero for either address family or socket type as a wildcard value."
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #4 from Dan Kegel dank@kegel.com 2012-06-01 00:44:33 CDT --- Created attachment 40355 --> http://bugs.winehq.org/attachment.cgi?id=40355 draft patch
The attached patch seems to get past the problem here, but I haven't verified that the listening socket actually works. Does it help for you?
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #5 from Bruno Jesus 00cpxxx@gmail.com 2012-06-01 06:42:11 CDT --- I read somewhere I can't remember now that you need to WSAEnumProtocols and pick the first one (possibly SOCK_STREAM as you did). I'll try to find this information again.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #6 from Dan Kegel dank@kegel.com 2012-06-01 09:18:08 CDT --- But in practice, I bet that will always yield SOCK_STREAM. It would be easy enough to verify that the created socket was SOCK_STREAM, at least on our little test cluster.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com 2012-06-01 10:30:52 CDT --- Sure, I do agree with that.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #8 from DieCore diecore64@gmail.com 2012-06-01 11:03:41 CDT --- Created attachment 40361 --> http://bugs.winehq.org/attachment.cgi?id=40361 Winsock log after the if type==0 patch
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #9 from Dan Kegel dank@kegel.com 2012-06-01 11:05:15 CDT --- Are you sure you built wine after the patch, and used the built wine?
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #10 from DieCore diecore64@gmail.com 2012-06-01 11:10:19 CDT --- (In reply to comment #9)
Are you sure you built wine after the patch, and used the built wine?
I think so i did it correctly.
1) i downloand wine 1.5.5 source 2) open the wine-1.5.5/dlls/ws2_32/socket.c with kwrite and i added the patch 3) i uninstalled wine through yast 4) i build wine and did a make install 5) i recreate the ./wine configuration because i had this problem: wine: '/home/diecore/.wine' is a 64-bit installation, it cannot be used with a 32-bit wineserver. 6) i reinstall proteus 7.10 on that clean ./wine
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #11 from Dan Kegel dank@kegel.com 2012-06-01 11:33:50 CDT --- Created attachment 40362 --> http://bugs.winehq.org/attachment.cgi?id=40362 More verbose version
Try this one, it's a bit more verbose. With it, I see
trace:winsock:WSAStartup verReq=2 trace:winsock:WSAStartup succeeded trace:winsock:WS_socket af=2 type=0 protocol=0 trace:winsock:WSASocketA af=2 type=0 protocol=0 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW af=2 type=0 protocol=0 protocol_info=(nil) group=0 flags=0x1 fixme:winsock:WSASocketW Defaulting to SOCK_STREAM trace:winsock:WSASocketW created 00bc trace:winsock:WS_bind socket 00bc, ptr 0x89f6e4 { family AF_INET, address 0.0.0.0, port 8000 }, length 16 trace:winsock:WS_listen socket 00bc, backlog 2 trace:winsock:DllMain 0x7dfa0000 0x2 (nil) trace:winsock:WS_accept socket 00bc
when starting up the app with debug socket checked.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #12 from DieCore diecore64@gmail.com 2012-06-01 15:02:47 CDT --- Thank you so much guys and especially Dan Kegel who made the patch!
The patch works for me too now!!!
I had copy pasted wrong the first time...
I have tested with the linux version ofcourse :) of mplabX and it works!!!
Now we can use Proteus with wine and control it with mplabX almost native thanks wine :P No more virtual machine and windows just for that!
Please send the patch to wines main line ASAP so we can have it on the next release!!!
http://bugs.winehq.org/show_bug.cgi?id=30815
DieCore diecore64@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #13 from DieCore diecore64@gmail.com 2012-06-02 12:06:27 CDT --- The patch works perfectly! Please upload it to wine's mainline so it will be included to the next release!!!
http://bugs.winehq.org/show_bug.cgi?id=30815
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #14 from Juan Lang juan.lang@gmail.com 2012-06-02 12:08:31 CDT --- Not fixed until the patch is committed.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #15 from DieCore diecore64@gmail.com 2012-06-11 11:55:56 CDT --- Whats the procedure of committing a patch to wine's main git source code? Who is allowed commit? Anyone?
I checked the log of the latest wine 1.5.6 and i think it isn't committed. Am i right?
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #16 from Austin English austinenglish@gmail.com 2012-06-11 12:04:12 CDT --- (In reply to comment #15)
Whats the procedure of committing a patch to wine's main git source code? Who is allowed commit? Anyone?
http://wiki.winehq.org/SubmittingPatches
I checked the log of the latest wine 1.5.6 and i think it isn't committed. Am i right?
Correct.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #17 from Dan Kegel dank@kegel.com 2012-06-11 12:32:56 CDT --- I'll try to submit it soon.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #18 from DieCore diecore64@gmail.com 2012-09-04 14:02:16 CDT --- (In reply to comment #17)
I'll try to submit it soon.
Any news? Is it submitted?
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #19 from Dan Kegel dank@kegel.com 2012-09-04 14:11:43 CDT --- It dropped off my radar. I'll try to have another look.
http://bugs.winehq.org/show_bug.cgi?id=30815
Olli Salli ollisal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ollisal@gmail.com
--- Comment #20 from Olli Salli ollisal@gmail.com 2012-09-22 04:19:11 CDT --- Polar WebSync 2.6 HRM software also seems to need this, otherwise the background daemon doesn't start properly. Please commit to mainline :)
With my (superficial) WinSock knowledge, the patch seems OK. If you need a datagram (UDP) socket, you're going to request it separately. The only situation where this could behave differently in real Windows is if you have the entire TCP/IP stack disabled and it gives you a netbeui/ipx/etc legacy socket. And I don't think you can even do that in any Windows version past 2000. Bruno's suggestion from comment 4 could fix this too, but I'd say it's just unnecessary overhead.
(Partial) log without this patch from the Polar software:
fixme:winsock:convert_socktype_w2u unhandled Windows socket type 0 fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000002,(nil),0x0002,0x00000000,0x97d160,(nil)): stub err:eventlog:ReportEventW L"\n\n" err:eventlog:ReportEventW L"Caught class Polar::Net::Exception...\n...Caused by class Polar::System::Exception. 10041: ...\n...Server shutting down."
10041 is WSAEPROTOTYPE, so clearly this is the issue.
http://bugs.winehq.org/show_bug.cgi?id=30815
--- Comment #21 from Olli Salli ollisal@gmail.com 2012-09-22 04:19:52 CDT --- (In reply to comment #20)
Bruno's suggestion from comment 4 could fix this too,
Actually comment 5 :eh
http://bugs.winehq.org/show_bug.cgi?id=30815
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|wine-bugs@winehq.org |00cpxxx@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30815
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |32412
http://bugs.winehq.org/show_bug.cgi?id=30815
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|32412 |
http://bugs.winehq.org/show_bug.cgi?id=30815
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |35e54fa59bf4b45abfa18e2323a | |590bc3c673498 Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com 2013-09-17 18:18:31 CDT --- This bug was fixed by http://source.winehq.org/git/wine.git/commitdiff/35e54fa59bf4b45abfa18e2323a...
http://bugs.winehq.org/show_bug.cgi?id=30815
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #23 from Alexandre Julliard julliard@winehq.org 2013-09-27 13:41:48 CDT --- Closing bugs fixed in 1.7.3.