There are three solutions:

• Install a web server on each machine. This can be pure-Perl, like dhttp or Jellybean, or the old standby of Apache or PWS, or even the one from Indigo Perl.
• Rewrite your application not to speak HTML/CGI. Add an interface, whether Curses, Tk, GTK, QT, Win32, or what have you.
• Add some client-side processing with JavaScript to offload work from the server. Tough to do securely, maybe hard to do in a cross-platform, standards-respecting manner.

How does your program on the website send data to the CGI script? Does it do a form submit itself? Why does it matter that the program is on the website? Where does the HTML page go when it's generated? Back to the program that submitted the form data? Why? How did you convert the perl script to the exe? What happened to the other program (the one that was doing form submits)? Which "that exe" are you referring to -- the first one that sends data to the CGI or the Perl script that was rewritten in C++? How did you try to submit form data to the C++ exe? Is it accessible to a web server somewhere? If not, how did you submit it?

Anyway, it's all very confusing.

If you mean, "how do I make a web-based application work on an arbitrary machine", you probably need to get a web server.

If you just want to run some CGIs and serve some static pages on someone's desktop machine, get a little web server to run there. Since you have Perl, let me suggest HTTPi which is a nice small web server that's easy to set up and is in portable Perl.

Ok, first off I can't set up a web server on every person's machine so that's not gonna work. And the reason I need to get this cgi script off of my host because it's simply comsuming to much bandwidth and besides it takes a long time to load because of all the data it must transfer.

Basically you have a html page with a form on it. FORM name=generatemap action=../cgi-bin/mapeditor/upload.cgi method=post target=map encType=multipart/form-data and a few fields in the form INPUT type=radio value=open name=ac etc... etc... exactly what type of input fields doesn't matter
the user clicks on the submit button
then, the data is submitted to the cgi (upload.cgi) like I mentioned before.
upload cgi then generates an html page that the viewer sees in their browser (of course)

Now I have converted the perl script into a c++ exe.... The problem is if I put the html page and the exe on my local machine instead, then when I click the submit button it asks to download the exe instead of running it.

And so that's what I need a solution to.
As for what I used to convert the perl to an exe, well that don't matter much. I can just as easily recode the program in c++. However, I did try this program: http://www.indigostar.com/perl2exe.htm

Why can't you set up a local web server? It doesn't have to accept connections from other machines. Many products do it... we're only talking about a single Perl program, not something like Apache. You may want to use a port other than port 80, but you can do this with an 8K program and provide an entire web environment, into which you can add other CGI and/or static pages.

If you want a stand alone application - write a stand alone application, Tk would provide an adequate UI. Get ready to waste lots of time installing it and keeping it upgraded, however. A better route would be a networked application, where a central server does the majority of the computing and the clients provide the UI.

If you want a networked application, you will have to do the socket connections yourself (be sure and take a gander at CPAN first - lots of wheels ready to roll). You will need to write a server program that runs on a central box in your network, and you will need to write the client program to talk to the server on a designated port. Then you install the clients as needed on the other boxes in your network (of course, now you are back to having to maintain upgrades).

But why do that when it has already been written. It's called HTTPD!

So, what i am getting at is that you are trying to solve the problem with a purple banana - wrong solution! What you need is to beef up the server - either with hardware or by switching from plain-jane CGI to mod_perl.

The former is easier, but the later is cheaper (free!) and worth the trouble in the long run.

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

From your clarification, you need to inform your http server to treat your .exe as CGI. It might be as simple as renaming it to .cgi extension, or you may need to 'AddHandler ...' in .htaccess.

The idea of uploading the .exe to every client is a non-starter. Aside from no sane client letting you do that, the bandwidth cost would eat the cpu time savings. That is the^Wone flaw in the Java applet idea. A faster server may be the real fix.

After Compline,
Zaxo

1. If your CGI is in Perl and your local machine is Windows then install ActiveState Perl (www.activestate.com) on your local machine.
2. Then read the documentation on Perlscript which comes with ActiveState Perl.
3. Basically you will cut and past your entire Perl CGI script into the HTML page that you are serving up. You will place the CGI script inside <script language = "Perl"> ... </script>tags.
4. Finally attach the script to some button or other HTML object on the page, perhaps using the "action =" attribute on a form button. With some fiddling around your script will perform inside the client browser the same way that it would have on the server.

A browser connects to a port (usually 80). If that executable is listening on one, you can use it. It's technically not impossible for an executable being both daemon and plain shell app, depending on the call, but I doubt you have that. Ofcourse there is also the matter of completly handling HTTP headers, since the webserver normally does... You'll always need a webserver to connect to, even if your script is the webserver itself.

Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.

You can certainly take a Perl script, and turn it into an .exe file. I just ran a simple test using PerlApp to create a standalone executable out of a very simple Perl script. The fact that your browser is being passed an entire file for download means that your web server did not see the target file (YourScript.exe) as a file to be parsed/executed. You must make sure that your web server has been setup correctly (as Zaxo points out).

If you really would like to completely offload the work to a client's machine, then I would suggest installing your .exe as a listening service on the end users machine. This would not be a full fledged web server, but rather a simple program that only listens for specific data on a specific port (like the idea that Beatnik was suggesting). You could then redirect your HTML FORM tag to post to the localhost on your listening port.

Of course this whole scheme will require you to get the end user to install the listening service.

If you do not desire to have the end user install programs locally (issues with different operating systems, and end user know how), then you will probably have to use a language/facility that is supported in the browser. Such as stand alone applets, ActiveX applications, and perhaps even simple Javascript and or VBScript.


Chris
'You can't get there from here.'