Comment by dragontamer
4 days ago
Really? It's a bit of a nonsense that I did so long ago so it's weird to hear someone interested in it...
The script has been lost to time. I wrote it 5+ computers ago and I don't even know where input that backup...
The overall gist is that CGI Bin specification sets Environmental variables, STDIN and STDOUT to various values. A minimal pure assembly that writes <h1> Hello World </h1> over stdout is your minimalist CGI Script.
A bit of research into what those STDIN/Environmental variables is needed for more. I knew this may e 20+ years ago but have long forgotten....
With access to the various input parameters offered over CGI, you can easily access form data (buttons and whatever clicked by the user). Use some smart file writing to store sessions and off you go....
-------
Maybe start with a Perl CGI tutorial. Then go backwards to C, and finally raw assembly by hand
Aw, that’s too bad. Sounds like it was a really fun project.
Thanks for the tips on CGI! Definitely going to look into it more. The server-side execution of CGI scripts definitely interests me more than the CGI scripts themselves, so I’ll probably just look for some existing (simple) CGI scripts and work on building the env vars and executing them.
Implementing a web server that can do CGI is actually probably easier than writing a CGI app. All you have to do for your server is set some environment variables and then spawn the executable.
It was a small "app". But I do remember writing string parsers in Assembly.
My overall lesson was to stick with Perl / CGI-bin.
That being said, I wrote in "Human Readable Assembly" back then. Ex: function calls were:
I would put compile time constants after the functions. Then I would before returning, pop the return address off the stack and add reg, 1, and push it back on.
It's horribly inefficient to do this today. But it allows you to write more flexible assembly functions that were more readable. Especially with macro-assemblers with some kind of preprocessor.