I'm still writing CGI exe's (actually CGI's and ISAAPI dll's).

I wriite them in Borland's Delphi 7.

I use FoxPro DBF's or plain text files as a database.

For low-medium traffic sites, this works great.

The best part is that it doesn't require any special services from the webhost, so if my client is on say XO or whatever, I can write an exe for the cgi-bin with some subfolders, upload it, and they're ready to go. No ODBC, no database-server space, etc. Obviously though a Windows server is required for running Windows exe's.

I use the custom-tag-based programming method. I create template html files entirely separate from the code, and the code loads the template file, replaces the tags with database data or session data, and pumps out the html.

I prefer to use cookies to identify a session, but I never store anything but session identity info in a cookie (no user data). The cookie is then used to retrieve the user's data on each posting of form data or link-click.

It's best that the cookies not be assigned using sequential id numbers, because a wise-guy could modify the cookie, bumping up the number, and see what they get. I usually use 32-byte random number/letter combinations. Also, the cookie is encrypted. This is pretty good (but my clients' sites are targets only for automated hacking attacks, not targeted missions by the mob).

I believe this type of development is slightly slower than PHP or ASP development, especially when doing a kind of site you haven't done before, but can be much faster on the 2nd outing for any kind of site, in keeping with general truths regarding the productivity of the programmer vs. the productivity of the language or platform.

A big positive is the *solidity* of this kind of programming. Delphi is not subject to buffer overruns, but I check all incoming form variables for length and illegal characters anyway.

Typically, once a site is working, it will never exhibit bugs. One gothcha is unannounced server reconfigurations so beloved by virtual hosting companys. For example, when XO upgraded their servers from WinNT to Win2K, all permissions were left behind, requiring a support call. Then they went to Win2K3 a few months later, same thing.

Other than that though, the apps are rock-solid. It is possible to handle up to 100,000 records using Delphi and plain *text* files as a database (using a simple trick or two), or for a more than three-table database, old-fashioned FoxPro dbf's.

I know PHP reigns supreme, followed by ASP, but I'm still having good results with this system. Of course, I have a good library of code built up.

Anyone relate?

PHP and ASP (not ASP.NET) comes for small and medium project. You are right, that this kind of programming is *solidy* but as for me it's better to use Java Server technologies with special libraries like Struts.
Now i'm writing web-server based on Indy components and uses Interbase database (i use CBuilder for it) and can say, it requires more time to develop, than PHP takes. But the code is more organized, than PHP's
So for each project there is specific technology...

The big advantage to me of creating CGI EXEs in Delphi is that the language is totally familiar (if you are a Delphi developer) and you have loads of flexibility -- more than with most scripting languages IMHO.

Plus, if you do need to go to ISAPI it's a straightforward step and you can get astounding performance from well-written ISAPI DLLs -- we also publish The Delphi Magazine and I remember an article we carried based on a case study and the guy had done some amazing stuff.

Delphi's just great!

Originally posted by TDMWeb
Delphi's just great!

Well, I logged back in here fully prepared for an awful flaming and instead found that I have some company in using Delphi!

Thanks for the posts, guys.

I use CGIExpert plus some INDY. When I started with CGIExpert, there was no webbroker, and when webbroker came along I never saw a reason to switch, so I've never used it.

Not sure why we're discussing CGI still in this age of better performing technologies. CGI served its purpose but there are several better technologies that are more "solidy" that CGI. With CGI you have to worry about recompiling to another platform (Linux and Windows) Hell, worrying about compiling is a PITA enough. Next is the overhead each instance of the CGI executable gets. Slows down performance and requires more system resources the more concurrent hits you have. For platform independance I'd suggest php. For performance, ASP.net. You may notice a good amount of the heavy usage sites are using ASP.net now. ;)

Originally posted by Talegen
Not sure why we're discussing CGI still in this age of better performing technologies. CGI served its purpose but there are several better technologies that are more "solidy" that CGI.

Actually, compiled languages are more predictable and solid than interpreted ones, in my experience. This is due to the simple fact that the compiler has validated *all* of the code. With interpreted languages, I have seen programs that worked for years and then suddenly surfaced bugs because some new set of conditions has caused the code to follow a path through conditional code that was never executed before.

Next is the overhead each instance of the CGI executable gets. Slows down performance and requires more system resources the more concurrent hits you have.

CGI is convenient for use at virtual hosts where you can't reboot or restart a service or dll. However, there are some specialized virtual hosts that have this capability (defined.net for example).

But actually I was referring to exe's/dll's in general, including ISAPI dll's which are always loaded and do not have the concerns you raise.


Hell, worrying about compiling is a PITA enough.

Yes, compiling code typically eliminates the convenience of editing your code directly on the production server. But that's a good thing IMHO. FYI, Delphi (but not C) can recompile a typical web project in 5 or 10 *seconds*, even when doing a complete build.


For platform independance I'd suggest php. For performance, ASP.net. You may notice a good amount of the heavy usage sites are using ASP.net now. ;)

Yes, the chief disadvantage of Windows EXE's is the lack of "platform independence" (you do have your choice of Windows NT, Windows 2000, or Windows 2003 <bg>).

The really cheap deals for hosting and dedicated servers are all on Linux, it's true.

Like I said, PHP reigns supreme for automation on the internet, I know and respect PHP programmers, but it's not my thing.

I've used ASP - and fixed a lot of other people's ASP <g> - but I was never a big fan of VB or VBA.

ASP.Net is intriguing and I plan to use it - Delphi for .Net (pascal/delphi) has just come out. Unfortunately, not all Windows virtual server hosts offer it yet. Probably when Frontpage includes .Net features, they'll all have to offer it.

So my strategy is to say with CGI exe's for small sites and quick projects, and go to ASP.Net via Delphi for .Net as it gains prominence, most likely after the next Visual Studio release this year, because Microsoft has made it clear that VB.Net and .Net will plug a lot of holes that people are spending time now coding around.

Thanks for sharing your comments.

Originally posted by cyberbeach
Actually, compiled languages are more predictable and solid than interpreted ones, in my experience. This is due to the simple fact that the compiler has validated *all* of the code. With interpreted languages, I have seen programs that worked for years and then suddenly surfaced bugs because some new set of conditions has caused the code to follow a path through conditional code that was never executed before.


At least in regards to ASP and ASP.net the entire script is run through the parser before execution. In ASP.net's case it's compiled. If a parse bug exists, it will state it. Regarding comparisons between errors found late. The same problems can exist in either type of method. I can have a divide by zero in a CGI app just as easily as ASP or other script language. Hopefully we're testing all facits of our applications to make sure there aren't any hidden surprises. :)

My experience with "CGI Applications" (refered here on out as CGI) on multiple platforms was with writing my own search engine a while back. All I recall i was writing C code, uploading the source to the linux box. Telnet'ing into the account. Running gcc, if it compiled without errors, move the exe to the CGI-Bin folder, test the script on the web server, etc. If it failed, start again. With scripting code like ASP you get the chance to debug through the server.

Originally posted by cyberbeach

CGI is convenient for use at virtual hosts where you can't reboot or restart a service or dll. However, there are some specialized virtual hosts that have this capability (defined.net for example).

But actually I was referring to exe's/dll's in general, including ISAPI dll's which are always loaded and do not have the concerns you raise.


I wouldn't lump ISAPI into CGI. Pretty much the only thing in common is they're both compiled and both are used through a web server. ISAPI is more of a web server extension executed in the server's process context than a seperate executable. Thus the reason why ISAPI is so fast, and desired for IIS development. Through VS.net the JITc essentially compiles ASPX files to ISAPI extensions. That's why it's the best of both worlds and why I am liking it lots. :)

Originally posted by cyberbeach

Yes, compiling code typically eliminates the convenience of editing your code directly on the production server. But that's a good thing IMHO. FYI, Delphi (but not C) can recompile a typical web project in 5 or 10 *seconds*, even when doing a complete build.

I didn't have a problem with compiler time. Most of my CGI code was pretty small back in the day. It's just a matter of the process of updating scripts that was tedious for me at least. If I can map to a shared folder, edit files right on the dev machine and refresh the browser when done to see results, that's gonna save me time, and ultimately money. Hopefully you're using a dev server now.
[QUOTE]Originally posted by cyberbeach

Yes, the chief disadvantage of Windows EXE's is the lack of "platform independence" (you do have your choice of Windows NT, Windows 2000, or Windows 2003 <bg>).


True, but the same can be said for any OS's executables. Thus why everyone moved away from CGI to more platform independant scripting systems.

[QUOTE]Originally posted by cyberbeach

The really cheap deals for hosting and dedicated servers are all on Linux, it's true.

Very true. They have less overhead thus "give away" services. Without trying to offend anyone, I believe Windows hosting is more of an "up scale" or "corporate" solution. It seems a lot of people want to host for as little as possible. They will get what they pay for in the end.

[QUOTE]Originally posted by cyberbeach

Like I said, PHP reigns supreme for automation on the internet, I know and respect PHP programmers, but it's not my thing.

I've used ASP - and fixed a lot of other people's ASP <g> - but I was never a big fan of VB or VBA.

I'm not sure if PHP reigns because it is superior or because it's for the most part portable. One could argue points for both camps. If you're talking about just the Windows world, then I'd say ASP reigns supreme. Also there's always ASP with JScript ;)

[QUOTE]Originally posted by cyberbeach

ASP.Net is intriguing and I plan to use it - Delphi for .Net (pascal/delphi) has just come out. Unfortunately, not all Windows virtual server hosts offer it yet. Probably when Frontpage includes .Net features, they'll all have to offer it.


I think one of the most awesome things about the .NET framework is that it's programming language independant. Meaning you can plug in a new language parser. Thus the reason why I call .net the "Java killer" Hell, I can devleop in J# already. lol. Most windows hosts offer .NET now. If they dont, then they're behind the times and need to get moving.

[QUOTE]Originally posted by cyberbeach

So my strategy is to say with CGI exe's for small sites and quick projects, and go to ASP.Net via Delphi for .Net as it gains prominence, most likely after the next Visual Studio release this year, because Microsoft has made it clear that VB.Net and .Net will plug a lot of holes that people are spending time now coding around.
Thanks for sharing your comments.

Sounds like a plan. For me, writing CGI isn't an option anymore. I'm sure for small applications, if the code is proven, and CGI is available, and it's not a load intensive application then using CGI could be a benefit. :)

Cheers!

As a Delphi programmer myself, I used CGIExpert in the past for CGI EXE and it was actually quite a great tool to use that is until I discovered Developer Express ExpressWeb Framework and now I have not turned back. EWF does help with the visual and it does have tons of very niffy tricks such as the famous DevEx Grids. It definitely helps me gain productivity because at least now I could develop web application as if I am developing standalone apps with some differences. Of course now I use ISAPI DLL exclusively and no more CGI and it sure loads a lot faster than before.

For database backend, I am using Elevatesoft DBISAM and it sure is great.

My clients are pretty happy with the results and thus we are getting repeat contracts because of it.

Originally posted by eddy2099
As a Delphi programmer myself, I used CGIExpert in the past for CGI EXE and it was actually quite a great tool to use that is until I discovered Developer Express ExpressWeb Framework and now I have not turned back.

Obviously I've great things about ExpressWeb.

I looked very seriously at ExpressWeb (and Intraweb) but I was conerned about the learning curve, and also concerned about Developer Express's commitment.

There were also deployment concerns - as I recall, you needed a virtual folder which means it's not good for generic virtual hosts (except Delphi-specific ones).

Possibly the confusion over whether to go with Intraweb or ExpressWeb caused me to go with neither <g>.

Anyway, I think I missed the boat. At this point, I don't see an advantage to getting on the ExpressWeb bandwagon - my next new platform will be .Net.

From an inside information, Devexpress would be releasing a new version of EWF pretty soon probably sometime within the next week or so.

Actually the virtual folder where the js and images which EWF uses is really no big issue. There was just too much confusion but as long as you place them in the root of your public_html folder, you do fine. Prior to getting my own W2K3 server, I was using virtual hosting for my clients site developed with EWF and there has never been a problem.

True, I played with Visual C# for .NET and I like that separation between the visual and the business object components. But the thing is that I am currently developing on my laptop and it does not work with Win XP Pro so it means no .NET development for a while. I am not prepared to give up my laptop for at least the next 12 months. I do have a Win XP Pro desktop but I travel quite a bit.

I did look at Delphi 8 but from what I read, the product is far from bug-free so I'll stay off it for some time until perhaps Delphi 9 or so. I am not sure if Delphi 7 is any indication of the commitment level of Borland to issue patches because after these almost 2 years using it, I still have not receive a patch for it as yet.

For me, EWF is the here and now and since I am using it right now, I don't see myself changing anything radically for a while. I'll probably maximize its usage and value until the day I have to move.

There is really no big learning curve to plunge into EWF. In fact, the language is pretty much Delphi-flavor of Pascal and the style of development you could easily adopt it from what you pick up from Delphi programming. It helps if you know how the other DevEx components work. In fact, it is really web development made easy.


But I understand your concern and your reasoning, .NET at least on the web is the here and now.. and tools are already available to support its development.

Originally posted by Talegen
At least in regards to ASP and ASP.net the entire script is run through the parser before execution. I really don't think that's correct in the case of ASP. I've seen completely bad code sitting inside an if/then, not getting executed and not causing problems - for the moment, and then boom.

I can have a divide by zero in a CGI app just as easily as ASP or other script language. Hopefully we're testing all facits of our applications to make sure there aren't any hidden surprises. :) In the case of Delphi, though (and .Net) you have structured exception handling.

My experience with "CGI Applications" (refered here on out as CGI) on multiple platforms was with writing my own search engine a while back. All I recall i was writing C code, That's why we have different experiences. When developing on the dev server, using CGIExpert, Delphi can actually step through executing code (no edit & continue like in VB though). You have full access to watches, breakpoints, etc.

I wouldn't lump ISAPI into CGI. Another cool thing about using CGIExpert with Delphi: you can develop while creating a CGI (easy to terminate and start again), and then when you've got it testing, there's just a property to change and you can compile the same code to an ISAPI dll.

I'm sure for small applications, if the code is proven, and CGI is available, and it's not a load intensive application then using CGI could be a benefit. :) I'm not suggesting those who are not using these tools run out and learn them <g>. Obviously, .Net would be the "next big thing" to learn now, or if you want platform independence, PHP (I'm leaving out Java which is huge because it's really a tool for the enterprise project).

But don't be too condescending about these kinds of apps. They run very very fast - like I said, I have one app that uses an 80-thousand-record textfile "database".

Also, a small CGI exe, say 300k, is going to be kept in memory by the Windows server because it's smart enough to do that. Yes, it still has to be "reloaded", sort of, but it's not really hitting the disk like you might think.

I don't know what you mean by load intensive. I do know that I can handle a few thousand visitors per day with cgi exe's and isapi dll's written this way.

For a few hundred-thousand visitors a day, I'd be using Java, but then I'd have 23 teammates, 4 managers, 2 dba's and my job would be devoted to maintaining one bean <g> with no understanding of the rest of the application, and that's not my thing at all.

PS I'm not trying to win anyone over to my way of doing things. My original message was motivated just by wanting to find out if there were any other Delphi/CGI programmers out there. However your comments are appreciated.

I can't really jump to every cool technology that comes along. Sometimes I have to stretch what I know to cover as much ground as possible. If I had been just wanting to learn the best webserver tools, I would have taken the time to learn PHP back when.

Fortunately, 90% of productivity and quality is programmer-based and not platform-based, so I compete pretty well.

Eddy2099:

Your comments have certainly got me me reconsidering EWF.

Wow! Go through DevExpress website and those whitepapers on EWF development.

Sadly they do not have a trial version of EWF but rather just a 60 days money back guarantee.

Originally posted by eddy2099
Go through DevExpress website and those whitepapers on EWF development. You know, a year ago I did. I had decided to get EWF. I alreadly have QuantumGrid 3. So I was thinking, well, I could upgrade to QG4 and get EWF, and if I was going to do that, then I might as well buy their subscription.

Then the money required got so big that I never bought it, without ever actually "deciding" not to.

I actually went for their subscription plan in December because there were some new components which may be of help. Besides, I like what they do and I do not see myself getting out of Delphi for sometime now.

I know, the subscription cost did seems quite expensive.. money I did not have to spare in the beginning but now my situation has changed ever since I got EWF :) In fact, that is the most used componets apart from DBISAM for my Delphi web development.

I'm not trying to sway anyone either. After reading your first post it kind of made me wonder, "so?" That's the only reason I responded. :)

I wont get into specifics for simplicity's sake but I will follow up with the following bits of info. Perhaps it can help some when discussing these technologies.

Compair:

.... logic error

vbscript:
If something = 0 Then
x = 1 / something
End If

C:
if(something == 0)
x = 1 / something;

Both of these will compile and will throw an error

..... syntax error

vbscript:
Response.Write "value

C:
printf("value);

Both of these will not compile and will cause an interpreter error

So you see, vbscript (asp) will detect syntax errors when it parses the source just like the C interpreter.

and yes, being able to try and catch exceptions is a great thing for asp.net. :) A lot better than having to write on error resume next.

Another cool thing about using CGIExpert with Delphi: you can develop while creating a CGI (easy to terminate and start again), and then when you've got it testing, there's just a property to change and you can compile the same code to an ISAPI dll.

That is cool.

Java wouldn't use it for anything now. lol.

But don't be too condescending about these kinds of apps. They run very very fast - like I said, I have one app that uses an 80-thousand-record textfile "database".
Also, a small CGI exe, say 300k, is going to be kept in memory by the Windows server because it's smart enough to do that. Yes, it still has to be "reloaded", sort of, but it's not really hitting the disk like you might think.

I try not to sound tooooo condescending. ;) My point regarding this though is that it may run great with 1-15 concurrent users but after that your server performance takes a dump. Stress test your apps yourself and find out how many concurrent sessions you can handle. Hopefully you have a lot of RAM. :) Also each time your CGI is called the server takes a performance hit because the server has to spawn a process for that executable, including the overhead of the CGI environment itself. It may not necessarily be accessing the disk for the exe (probably from process cache) but it does take a toll when adding up concurrent clients. Accessing a 80k flat file also takes a hit on server performance. You're dealing with file handles, locks, etc on the system. A database server can do that a lot more efficiently. If flat files were better, we'd all be using them, right?

I don't know what you mean by load intensive. I do know that I can handle a few thousand visitors per day with cgi exe's and isapi dll's written this way.

Load intensive = 50+ concurrent users accessing your site and your CGI script. The server will bog if it becomes low on resources. ISAPI is more efficient in resource usage (handled by server) and thus is faster and allows more concurrent users.

For a few hundred-thousand visitors a day
I'd probably stick with some form of ISAPI or .net. I'd definitely want to scale up/out the servers to load balance them. That's a pretty good amount of users. about 3 hits / sec.

I'm not trying to win anyone over to my way of doing things. My original message was motivated just by wanting to find out if there were any other Delphi/CGI programmers out there. However your comments are appreciated.

That's cool. I am just putting my 2 pennies in the pot. I was just interested to know why people would still use cgi. :)

I can't really jump to every cool technology that comes along. Sometimes I have to stretch what I know to cover as much ground as possible. If I had been just wanting to learn the best webserver tools, I would have taken the time to learn PHP back when.

It gets really expensive too. lol. Since my developer roots are from a wintel/VB background I lead toward anything that has VB syntax. I am loving .net.

Fortunately, 90% of productivity and quality is programmer-based and not platform-based, so I compete pretty well.

If you are lumping in "technologies" in to "platform" then I'd say it's 70/30. :)

Best of luck in all your endeavors!

-Rob-

I usually say,

"You don't always get what you pay for, but you almost never get what you don't pay for."

PS: At least neither of us is using Perl, the write-once read-never language (he said quietly, hoping not to come to the attention of the Perl armies...) :)

I own a Perl book. lol. The book's spine has no crease. I think I used it for a CGI project once. lol.

Originally posted by Talegen
I own a Perl book. lol. The book's spine has no crease. I think I used it for a CGI project once. lol.

I actually used to mess with Perl - modifying existing scripts. Had the Perl bible or something like that. This would be in the 1995-1997 timeframe.

The regular expressions may be "powerful" but it takes me way longer to decipher one line of Perl than 10 lines of procedural code doing the same thing.

Remeber Matt's Script Archive? When formail.pl was the leading edge of technology?

lol yeah! I had to "learn" perl just enough to fix someone else's script too. I was more partial to C myself back in the day and yes I could spit out C faster than Perl. lol. ahhh memories. lol.

I really liked perl when I learned it last year. But then I found out what a horror it can be trying to understand your own code 6 months after you wrote it. :)

Cgi in my favorite code environment, Delphi, would fit like hand in glove. Do any web hosts allow that? You guys must be talking about dedicated or colocated situations.

Originally posted by jpartridge
Cgi in my favorite code environment, Delphi, would fit like hand in glove. Do any web hosts allow that? You guys must be talking about dedicated or colocated situations.

I've always been able to run Delphi CGI exe's on any hosted win server. Once in awhile, you have to ask them to turn on permissions.

If you have a hosted server, you can run the same code as an ISAAPI DLL. Or if you have hosting from a specialized host such as defined.net.