3 ms·

How did you make a Windows executable work on the web?

by mattl 3y ago

franzb 3y ago
I imagine it ran server-side (on Windows).
- bruce511 3y ago
  Indeed. I think it's worth going a little deeper for those who perhaps aren't familiar with some of the underlying principles of the Web. For starters, all the program does is receive requests (as text) over a TCP/IP connection. It replies over the same connection. So writing a Web server in any language, on any OS is a trivial exercise. (Once you have the ability to read or write TCP/IP. The program has to accept the input, calculate the output, and send the output. If the input is just file names, then the program just reads the file and sends it. (Think static site). The program may parse the file, and process it some more. It "interprets" code inside the file, executes it, and thus transforms the output. Think PHP. In these cases a generic server fits the bill. Think Apache, IIS, nginx and so on. The next level up are programs that are compiled. They generate the output on the fly, often with no, or little, disk interaction. This sort of program often uses a database, but might not. (An online Soduku game for example might do everything in memory.) Again, any if the above can be built on any OS and written in any language with TCP support.
sedatk 3y ago
Using CGI protocol on a Windows server. IIS (Windows' own web server) basically interfaces with executables by running them, feeding them HTTP headers, and server variables through environment variables, and gets the response HTTP headers and the body from their STDOUT. It's very inefficient, of course, since every request requires spawning a new copy of the executable, but it had worked fine in its first months :) Here is a very simple example from the original sources: https://github.com/ssg/sozluk-cgi/blob/master/hede.pas https://github.com/ssg/sozluk-cgi/blob/master/hede.pas
- dijit 3y ago
  Don't sell yourself too short here, that's exactly how Perl/PHP works and that was defacto standard around the same vintage (and for a decade more).
  - KronisLV 3y ago
    Honestly, there's a lot of beauty in that simplicity, I can definitely imagine someone also wanting to work with mod_php in Apache as well (just a module for the web server). That said, FastCGI and similar technologies were inevitable and something like PHP-FPM isn't much more difficult to actually run in practice. Still, having a clearly defined request lifecycle in wonderful, especially when compared to something how Java application servers like Tomcat/Glassfish used to work with Servlets - things there have gotten better and easier too, but still...
    - whstl 3y ago
      Agree. I also loved the simplicity. It’s not that different from Serverless, if you look at it. There is an HTTP server handling all the HTTP stuff and process launching (which is handled by API Gateway in AWS, for example), and the communication between it and the “script” just uses language or OS primitives instead of more complex APIs. The 2000s were quite wild in how things changed… suddenly you have giant frameworks that also parse HTTP, a reverse proxy. At some point even PHP became all about frameworks. I wonder if we wouldn’t have a more open, standardized and mature version of CGI/Serverless if it had been a more gradual transition rather than a couple of very abrupt paradigm shifts.

How did you make a Windows executable work on the web?

by mattl 3y ago

How did you make a Windows executable work on the web?

franzb 3y ago

I imagine it ran server-side (on Windows).

bruce511 3y ago
Indeed. I think it's worth going a little deeper for those who perhaps aren't familiar with some of the underlying principles of the Web. For starters, all the program does is receive requests (as text) over a TCP/IP connection. It replies over the same connection. So writing a Web server in any language, on any OS is a trivial exercise. (Once you have the ability to read or write TCP/IP. The program has to accept the input, calculate the output, and send the output. If the input is just file names, then the program just reads the file and sends it. (Think static site). The program may parse the file, and process it some more. It "interprets" code inside the file, executes it, and thus transforms the output. Think PHP. In these cases a generic server fits the bill. Think Apache, IIS, nginx and so on. The next level up are programs that are compiled. They generate the output on the fly, often with no, or little, disk interaction. This sort of program often uses a database, but might not. (An online Soduku game for example might do everything in memory.) Again, any if the above can be built on any OS and written in any language with TCP support.

sedatk 3y ago

Using CGI protocol on a Windows server. IIS (Windows' own web server) basically interfaces with executables by running them, feeding them HTTP headers, and server variables through environment variables, and gets the response HTTP headers and the body from their STDOUT. It's very inefficient, of course, since every request requires spawning a new copy of the executable, but it had worked fine in its first months :) Here is a very simple example from the original sources: https://github.com/ssg/sozluk-cgi/blob/master/hede.pas https://github.com/ssg/sozluk-cgi/blob/master/hede.pas

dijit 3y ago
Don't sell yourself too short here, that's exactly how Perl/PHP works and that was defacto standard around the same vintage (and for a decade more).
- KronisLV 3y ago
  Honestly, there's a lot of beauty in that simplicity, I can definitely imagine someone also wanting to work with mod_php in Apache as well (just a module for the web server). That said, FastCGI and similar technologies were inevitable and something like PHP-FPM isn't much more difficult to actually run in practice. Still, having a clearly defined request lifecycle in wonderful, especially when compared to something how Java application servers like Tomcat/Glassfish used to work with Servlets - things there have gotten better and easier too, but still...
  - whstl 3y ago
    Agree. I also loved the simplicity. It’s not that different from Serverless, if you look at it. There is an HTTP server handling all the HTTP stuff and process launching (which is handled by API Gateway in AWS, for example), and the communication between it and the “script” just uses language or OS primitives instead of more complex APIs. The 2000s were quite wild in how things changed… suddenly you have giant frameworks that also parse HTTP, a reverse proxy. At some point even PHP became all about frameworks. I wonder if we wouldn’t have a more open, standardized and mature version of CGI/Serverless if it had been a more gradual transition rather than a couple of very abrupt paradigm shifts.