I know I'm late for Halloween but we are still between holidays. Back in 2012, I needed a way to start Apache in the background. No one had built anything (that I liked), so I over-engineered a solution:
https://github.com/cubiclesoft/createprocess-windows
It takes the core CreateProcess() Windows API call, soups it up, and makes nearly every option directly available to command-line applications and batch files.
Today I put the finishing touches on a wild new addition. The newest feature adds TCP/IP socket support, thanks to this StackOverflow post.
What makes the new feature scary is that ANY IP address can be used, not just localhost addresses. Therefore, you can have it connect out to a server on the Internet or a LAN (or your IoT toaster?) and, in fine unencrypted fashion, route data to/from the stdin, stdout, and stderr of ANY process of your choice. Security? What's that?
The feature was added to work around bugs in various scripting languages where they end up blocking on one of the three standard process pipes since pipes can't be easily switched to non-blocking mode on Windows. Using non-blocking, non-overlapped sockets solves the problem. Just don't use the feature for anything other than localhost IPs and everything will be fine.
https://github.com/cubiclesoft/createprocess-windows
It takes the core CreateProcess() Windows API call, soups it up, and makes nearly every option directly available to command-line applications and batch files.
Today I put the finishing touches on a wild new addition. The newest feature adds TCP/IP socket support, thanks to this StackOverflow post.
What makes the new feature scary is that ANY IP address can be used, not just localhost addresses. Therefore, you can have it connect out to a server on the Internet or a LAN (or your IoT toaster?) and, in fine unencrypted fashion, route data to/from the stdin, stdout, and stderr of ANY process of your choice. Security? What's that?
The feature was added to work around bugs in various scripting languages where they end up blocking on one of the three standard process pipes since pipes can't be easily switched to non-blocking mode on Windows. Using non-blocking, non-overlapped sockets solves the problem. Just don't use the feature for anything other than localhost IPs and everything will be fine.
Comments
Post a Comment