CGI Executable 4

[1DMF]

probably not the right forum, but you guys usualy know your chit!

what is a CGI excecutable, so when you put a URI in the address bar it runs the application on the server rather than tries to download the actual file.

What languages can this be written in?

Is this like Java or .NET ? I spoke with one programmer he said he was using Delphi.

What's the benefit / purpose of having a local exe , they said they could make it a DLL instead.

How can you put a URI of .dll and it run as an app in the browser? - could I do this with VBA.

what makes the browser run the app instead of trying to DL the exe file?

is this a safe way to access a website?

thanks 1DMF


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TonyGroves]

A CGI script/program is not run by the browser, it's run by the web server, which then passes the resulting output back to the browser in the form of a web page. It can be written in any language; Perl is popular, and for Microsoft servers Visual Basic can be used. Whether a certain file type gets downloaded from the server, or executed by it, depends on the server's settings.

 

[1DMF]

thanks, makes more sense now

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[stevexff]

From the browser perspective it sends requests for pages to the web server, which responds with HTML. Originally, these were just static files of HTML stored on the server.

CGI (and ASP, JSP, etc. for that matter) are just¹ ways of invoking a program on the server to create those 'pages' on the fly. This gives you the opportunity to read a back-end database to produce an up-to date list of products in stock, or maintain a shopping cart, for example.

But as far as the browser is concerned, it is still asking for pages, and receiving them. All the work is being done on the server.

¹ A gross over-simplification, but the principle is correct.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[1DMF]

I'm still a little confused, do you program the executable so it is still HTML, so if you have a button and you click on it, if it was a program running it would call a function/routine, as html it is either JS or a URI , i'm assuming that the button is desigen as if it was running local and the click causes the function to be called.

How does that all work?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[stevexff]

The HTTP protocol only supports a handful of requests, of which GET and POST are the most common. JS functions run on the browser; they may result in a GET or POST being sent to the server URL, often with a bunch of parameters strung on the end. The web server invokes the CGI program, which interprets the request, and prints the HTML 'page' to send back to the browser.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[1DMF]

But what I mean is, if you wrote a VB program and compiled it to run on a client as standalone, the way you code is draw a button, that button has an event, which when clicked calls a function/sub routine.

do you not code the same way for a CGI exe?

what benefit is there in writing this was, why use delphi to create a CGI program and have it run as a dll on the server.

What does that give you over .NET, ASP, ColdFusion, PHP, PERL etc...

How does creating an application this way differ in the way you code standard web apps using HTML,ServerSide & JS.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[stevexff]

Thin client (browser) applications are easy to write, and easy to deploy. No code on the local machine (except for JS and maybe applets). You can roll out a new version overnight to all your users if you need to.

Fat or rich clients (possibly even rich, fat clients) can give a better user experience, although as this is at the expense of complexity (think EJB, remoting, RPC calls etc.) they are harder to code. The downside is that when you want to deploy a new version, you have to physically install it on the client machines.

Horses for courses, really.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[1DMF]

I appreciate this but the CGI exe is different again.

Delphi, is from the days of Borland (Paradox) it is not a web language persae.

So how do you write apps using a compiled exe/dll in a language such as delphi that runs in a web browser environment, this is what i'm having difficulty understanding.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TonyGroves]

Server apps have no involvement with your browser.

What usually happens is that when you click a button on a webpage, your browser sends a request to the server for a specific file. If that file is a static webpage, the server returns it. If the file is a program, the server executes
the program and sends back the program's output, which would normally be HTML. Now, the server program can be a normal program written in any (supported) language; the only big difference is that instead of interfacing directly with the
user, it just prints out HTML code.

 

[1DMF]

Nope still confused. Delphi is based on pascal and the NORMAL way you would code is as I described, surely the point of using delphi, is because it's your language of choice, but is not designed for web appps, but as I found out the other day you can run a compliled delphi dll as a web app.

it's not a script interpreted server side as most web apps work.

Am I to take it that the drawn button, the click event and function call, is compliled with a special compiler which compiles it in a way that the end result is CGI compatible.

Is this the different, it's to do with the compiler and the way it's compiled which deals with it being in a http environment?

So therefore as a programer you code as normal as if it's a stand alone program running locally and the compiled end result makes it CGI->HTTP compatible?

is that it?


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[stevexff]

it's not a script interpreted server side as most web apps work

actually, many of them are compiled. Java (JSP), ASP.NET, to name but a few. Perl, Python, and PHP are all interpreted. Browsers only understand HTML and client-side scripting.

If the Delphi IDE holds your code, screens, buttons etc. as metadata, then it is quite conceivable that it can generate either client server or web-based versions just by selecting the requisite option on the compiler. But for a web-based app, the result will be a server component hooked into the web server, serving up HTML to the browser.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[TonyGroves]

Your CGI apps do not deal with buttons and clicks; the only input they know about is whatever arguments are attached to the request the server receives. For example, the URL "

http://example.com/prog.exe?user=1dmf&lang=en"

represents a request to the server to run prog.exe with the arguments "user=1dmf" and "lang=en", and to return the output from that program, which the browser will then display at the client side. The only CGI-specific stuff your program needs to worry about are the input arguments (and possibly some other stuff that's not relevant here); apart from that it's just a normal program which happens to print out HTML. Delphi most likely has some libraries which can handle the arguments; if not, then it's probably just a matter of treating them like ordinary command-line arguments.

 

[ishnid]

Basically, CGI guarantees a few things about the environment a program is called with and how data is passed between the user and your program. For a GET request, the data passed via the browser is accessible in an environment variable called QUERY_STRING. If it's a POST request, the information will be passed through standard input. Both of these will be encoded in some way. Anything the script prints to standard output becomes what the user sees in the browser (this includes a necessity for a Content-type header).

All the Perl CGI module does is to parse that information, which is one of the reasons that it's easy to write CGI scripts in Perl. In reality, pretty much any programming language could be used to do that.

 

[1DMF]

Right so the fact they use Delphi and compile their code to an exe or dll is irrelevant. They still have to write it based around the CGI->HTTP standards.

So instead of designing a screen with the screen designer, they need to use html, does the delphi studio, have a "web app" environment, which is different to your standard "app" environment.

or is as simple as the code serves a web page, the webpage is normal HTML, the links/menu's call the executable, reads STDIN/QUERYSTRING and then they do the rest in the good old fashioned way in delphi, but any output still needs to be convered to HTML or at least html/text header must be printed first?

is that it

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TonyGroves]

Your Delphi program shouldn't need any special web-app environment; just get the arguments, do whatever processing needs to be done, and print out the appropriate HTML (preceded by the standard http header). If you want to discuss Delphi-specific aspects of this, the Delphi forum is the place to go.

 

[ishnid]

I've never used delphi so I can't comment on what the "good old fashioned way" is in delphi, or what the "screen designer" is.

It is indeed irrelevant how or with what the executable is compiled. The HTML links and menus don't call the script as such. They just request a page from a web server (by requesting a particular URL). If the script is set up as being a CGI script, Apache (for example) will execute the file, passing in the user-supplied data via STDIN or QUERY_STRING, as appropriate. It captures the program's STDOUT and presents it to the user. Typically, it would be HTML that would be printed to STDOUT but that's not a necessity: you can also pass out text/plain, application/pdf, etc.

As an example of how simple CGI really is, this is a perfectly valid Unix shell script that can be called as a CGI script:

#!/bin/sh



echo -e "Content-type: text/html\n\n";

echo "<html><body>";



echo "<p>The query string was:";

echo $QUERY_STRING;

echo "</p></body></html>";

Like Perl, that's interpreted, with the shebang line specifying what interpreter to use. A compiled executable that does the same thing would have the same effect.

 

[1DMF]

I guess I need to hit the other programming forums to get a better understanding of how you create a CGI executable.

I'm sure you could do this with VB as well , which might be part of what .NET is about.

Anyway thanks for your input


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[Kirsle]

For something extra to add:

From reading through the posts in this topic, there seemed to have been a bit of confusion about what a CGI executable does or its capabilities.

In most all programming languages there is support for making a graphical user interface, in which your program pops up its own windows with its own menu bars, clickable buttons, and other such widgets.

When a CGI anything (compiled or interpreted language file) is called, the server runs the program on the server side, and anything sent to standard output is sent to the browser.

That being said, if the CGI program was made to have a GUI, the end user won't see the GUI in their browser. Instead, of you had a monitor attached to the web server, the web server would start popping up GUI windows, since the program is being run on the server side.

If you wanted "web apps" in which custom GUI windows with your own menus and widgets appears on the client machine, then a Java applet is probably the way to go. CGI is only for server-side processing and returning of data to display in the browser, which is usually HTML (but it could be GIF binary image data, a plain text document, JavaScript, CSS, etc).

So, in Delphi, if you could write an app with a GUI with a button that would call another function within the Delphi code, this isn't possible with CGI. The best you could do is have the Delphi CGI print out JavaScript along with the HTML, so that when the button is clicked, it would run JavaScript functions which would in turn query the CGI again with a different set of arguments to get the desired result.

In other words, a CGI program runs, and finishes, and the output is sent back. By the time you see the page in your browser, the CGI program has run and finished and is no longer running. It would have to be invoked again for any new output you want from it.

-------------
Kirsle.net | Kirsle's Programs and Projects

 

[1DMF]

so why go to all the hassle of writing it in delphi and compiling it to what appears to be a dodgy looking URI.

Instead of using web languages which are specificaly made for this purpose?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.