I've been diving deep into Bentschi's socket library lately, actually rebuilding it from the ground up. While doing this, I've put together a few examples that demonstrate using its various features. One of these is a WakeOnLan script, similar to the one you've posted here. However, I've found that when broadcast mode is not explicitly enabled (and even when it is explicitly disabled), it still broadcasts just fine and the computer still wakes up. This effect seems to be reproducible in the original socket library, using your WakeOnLan script here by removing the line
UdpOut.enableBroadcast() (or changing it to disable). I've read repeatedly around the net that this should not work, even though it appears to work just fine on my system (Win7 Pro x64 running AHKU32). As far as I can tell, the
enableBroadcast method has never had much of an effect, as it would need to be called before
WSAConnect in the
connect method of Bentschi's library to actually influence the connection.
According to
the MSDN article for
WSAConnect, it should be failing when used for a broadcast address such as
255.255.255.255:
For connectionless sockets, name can indicate any valid address, including a broadcast address. However, to connect to a broadcast address, a socket must have setsockopt SO_BROADCAST enabled. Otherwise, WSAConnect will fail with the error code WSAEACCES.
However, as evidenced by my suggested modifications to this WoL code, this does not appear to be the case. I've tried to find anything describing this behavior, but unfortunately there doesn't seem to be much buzz on the web about code that shouldn't work working; almost all of it is code that should work not working. Can anyone help me figure out what is going on here?