Stunnix Perl Web Server - FAQ - Table of Contents
The only "common" operating systems SPWS does
not run on are
MacOS7, MacOS8 and MacOS9. SPWS works just fine on MacOSX.
ASP is Windows-only, ancient technology, so ASP is not supported by SPWS.
There are a lot of Perl frameworks for building dynamic web sites that are
much more flexible than ASP.
Yes, PHP pages are fully supported. Even ones encoded with
IonCube PHP Encoder and
Zend Encoder for
PHP are supported.
It is Perl code, but it's protected from analysis and illegal reuse
using our perl obfuscation tool -
Stunnix Perl-Obfus.
We greatly recommend all professional Perl programmers to use it for their
projects in order to protect their intellectual property.
Yes, we do provide such services. Please contact us at
sales@stunnix.com for more information.
You can use our
Stunnix Perl-Obfus -
tool for making Perl code unreadable for Perl, and use our
JavaScript Obfuscator and
VBScript Obfuscator for JavaScript and
VBScript.
No, Perl needs not to be installed to run SPWS if Perl interpreter is
included with SPWS. Just try our
sample
CDROM image.
If Perl interpreter is included with SPWS, it will just run from the location
it's put to (and in case of CDROM with SPWS - from CDROM); user won't have to
install it at all. Just try our
sample
CDROM image to see it yourself.
The SPWS for this CDROM will be started without any noticable effects
(except that mouse cursor will turn into hourglass a couple of times for
a fraction of a second), and the browser window will be opened with
start page of the site.
SPWS will stay running in background, in order next time CDROM is inserted
or browser-based application is run, the browser page will appear
immediately. The SPWS processes will be terminated on the user's logoff.
But it's greatly recommended to put some kind of "release CDROM" button on
link to your site, otherwise users of operating systems other than Windows
will be unable to eject CDROM with SPWS on it. There is a
special support for stopping and releasing media
in SPWS.
No, SPWS by default is configured not to listen on any network interfaces
except a special "
loopback" interface accessible only from the same
computer; programs from other computers will even be unable to know that
SPWS is running and will be unable to communicate with it in any way, so
it's safe to run SPWS even on computer directly connected to the Internet.
It
can be configured to accept connections from
other computers though.
Edit httpd.conf (residing in the same directory where startsite.pl resides)
replacing
host 127.0.0.1 with
host 0.0.0.0
Yes, of course. Even different CDROMs (or browser-based apps) can be run on
the same computer - each of them will get their own instance of SPWS.
To replace tooltip, edit "site/stunnixwebsrv/win32-trayicon.pl" file (it's Perl script), updating this line:
-tip => "Stunnix Web Server - http://stunnix.com/"
To translate menu items, edit "sub do_populate_menu_entries()" in that file.
There are a lot of tools to create icons. You can also draw them in Photoshop - see
this document
for more info (it contains generic info too, about resolutions of .ico files). There are a lot
of other documents out there. You can also order icon creation - it will cost you about $50 in
some studios.
Once you create an icon in .ico file format, you can use any tool that allows to edit "resources"
inside .exe files - just google for "replace .ico exe". One of them is Restuner tool.
Just replace file site/stunnixwebsrv/stunnixsrv.ICO with your icon.
Go to a directory with your Prototype, right click on "Run CD on MacOS X" (i.e. the icon used to start
SPWS on Mac), select "Show package content". A Finder window appears, go to "Contents", "Resources" directory.
There you will find file "stunnix" with ".icns" extension. Just replace it with your file in .icns format.
There are a lot of ways to create an .ICNS file, they are described
here.
The SSI in SPWS uses Perl operators
for SSI expressions - (e.g. eq instead of =, ne instead of != for stringwise
comparing, etc), but for other (non-conditional) SSI directives syntax is the
same. So you will have to rewrite your SSI pages or insert conditional
expressions with branches for SPWS and Apache.
The only change that is greatly recommended is addition of a link or button
to
stop SPWS and release media - otherwise users
on operating systems other than Windows will be unable to eject CDROM.
If your site was developed for Windows web servers, you may also will have
to ensure that case of filenames in filesystem matches case of filenames
that are used to refer to them in the site, otherwise your site won't
work on OSes other than Windows. So if you have file named
ProductInfo.html, then links to it using name
productINFO.html or productinfo.Html or even
ProductInfo.HTML will not work; you will have to link to it
only using name ProductInfo.html. If this is a great limitation
for you, please contact us and we will probably develop a solution.
No, they will work as is, though it's greatly recommended to switch
to
XCGI script execution framework.
Yes, you can - almost no porting will required.
You can use
FastCGI framework for testing
execution of your scripts (written using XCGI framework) while testing on
Apache since XCGI scripts can be run as FastCGI scripts.
The only potential problem is with SSI support since SPWS uses Perl operators
for SSI expressions - (e.g. eq instead of =, ne instead of != for stringwise
comparing, etc), but for other (non-conditional) SSI directives syntax is the
same.
When developing browser-based applications (but not CDROMs!) with SPWS
we recommend you to follow the approach we choose; using an installer
for application allows you to permamently install application AND perl
interpreter runtime to the user's hard disk (thus eliminating the time
need to extract perl interpreter and your site to some temporary directory);
it also allows you to show some License Agreement to the user
and to create some menu items for Programs menu. We recommend you to
use free
NSIS installer framework, it's
sufficiently advanced and powerfull for most uses.
Yes, a special solution exists - just uncomment the final "Set Env" directive
in the httpd.conf while you develop your code - this will make "slave"
SPWS process that executes XCGI to exit after serving each request; this
will grealty decrease performance of course.