das "sicherer" würde ich überdenken, besonders bei den letzten gemeldeten lücken ;)

ok, sicherer wahr der falsche Ausdruck dafür, was ich gemeint hab. Ich meinte, Absturz-sicherer, als wie wenn ich irgendeinen Mod installier, der net gscheit funkt.

Und ich hab mir schon gedacht, wenn ich da positives übern IIS schreib, dass ich auf massiven Widerstand stoßen werde. ;)

Also Perl ist sehr stabil und funkt einwandfrei... der IIS müsst nur CGI können, dann würde es funken..

Hmm. Das hör ich zum ersten mail, dass ein Webserver mit Perl-Interpreter eingeht. Ist doch ein 1000fach erprobtes Konzept.

Weiters: ASP hat nix mit einer bestimmten Sprache wie VB oder Perl zu tun. Ich kann innerhalb von ASP-Seiten sowohl Perl, VB, JS, Python, ....... verwenden, solange sich die Sprache in die MS-Scripting-Engine einhängt (ist sogar dokumentiert!!!!).

Also wenn, dann muss Dein Satz ".. ASP mit VB und AccessDBs/SQL Server ..." lauten.

@Snoopy: Es muss nicht immer CGI sein ;) Schau mal zu ActiveState.

Ich kenn ActiveState - was genau meinst du mit "ohne CGI"? CGI brauch ich doch zum Austausch zwischen dem Webserver und dem Skript... egal welchem Skript...

Da hast Du schon recht, wenn Du die Umgebungsvariablen, etc. meinst.
Aber so wie es FastCGI und mod_perl für den Apache gibt, existieren auch Perl-Lösungen für den IIS, damit er nicht für jedes Script einen komplett neuen Prozess anreissen und Perl komplett laden muss.

So z.B.
Perl for ISAP (Bei ActiveState Perl dabei) http://webcompare.internet.com/isapiperl/
Oder PerlEx http://aspn.activestate.com/ASPN/Downloads/PerlEx/

@_m3 stimmt...

Aber ich bin vom "gebräuchlichsten" ausgegangen - und das is für mich zumindest VB in Kombi mit ASP. JS und die anderen gehen natürlich auch.

Ich mein damit nicht, dass Perl "schlecht" ist, sondern, dass es nicht so gut mit dem IIS "harmonisiert" wie zB mit dem Apache.

Und ob das gut oder schlecht für Perl ist, sei dahingestellt :D ;)