Murga-Projects Forums
murgaLua CGI %ENV - Printable Version

+- Murga-Projects Forums (http://www.murga-projects.com/forum)
+-- Forum: Project Forums (/forumdisplay.php?fid=1)
+--- Forum: MurgaLua - General (/forumdisplay.php?fid=2)
+--- Thread: murgaLua CGI %ENV (/showthread.php?tid=307)


murgaLua CGI %ENV - dvw86 - 03-23-2008 06:42 AM

I'm using Pupeee Beta 4 (based on Puppy Linux 3.01), the latest Monkey Web Sever, and murgaLua as a CGI language. This works well but i can't figure out how to call the system variables for the CGI. In Perl you can get them like this:

Code:
print "Caller = $ENV{HTTP_REFERER}\n";

Does anybody know how to call them in murgaLua?


RE: murgaLua CGI %ENV - Juergen - 03-23-2008 08:30 AM

That would be

Code:
print("Caller = "..os.getenv("HTTP_REFERER"))


But you shouldn't use murgaLua for CGI scripts. murgaLua is packed and has therefore more than an order of magnitude startup overhead (on my system it is more then 30x compared to stock lua5.1). Since there is nothing in murgaLua that isn't available elsewhere (except for the fltk bindings, which I guess you don't want to use in a CGI script ;-) there is no reason to use murgaLua for CGI scripts.

If you want to use it anyhow, it might make sense to unpack it (if the CGI script isn't only called once in a while) with "upx -d murgaLua". This way there is only a 8x startup overhead (on my system). Of course this applies to hot caches. With a cold cache the overhead might be smaller, due to the reduced binary size.

Juergen


RE: murgaLua CGI %ENV - dvw86 - 03-23-2008 09:25 AM

Juergen Wrote:
That would be

Code:
print("Caller = "..os.getenv("HTTP_REFERER"))


But you shouldn't use murgaLua for CGI scripts. murgaLua is packed and has therefore more than an order of magnitude startup overhead (on my system it is more then 30x compared to stock lua5.1). Since there is nothing in murgaLua that isn't available elsewhere (except for the fltk bindings, which I guess you don't want to use in a CGI script ;-) there is no reason to use murgaLua for CGI scripts.

If you want to use it anyhow, it might make sense to unpack it (if the CGI script isn't only called once in a while) with "upx -d murgaLua". This way there is only a 8x startup overhead (on my system). Of course this applies to hot caches. With a cold cache the overhead might be smaller, due to the reduced binary size.

Juergen


Thank you. The reason I was going to use murgaLua was two-fold. It is already in Pupeee and it can access/modify SQLite databases. Lua is so small that I don't mind installing another copy of it, but would it have SQLite support?


RE: murgaLua CGI %ENV - Juergen - 03-23-2008 09:48 AM

dvw86 Wrote:
Thank you. The reason I was going to use murgaLua was two-fold. It is already in Pupeee and it can access/modify SQLite databases. Lua is so small that I don't mind installing another copy of it, but would it have SQLite support?

There are multiple SQL database and SQLite bindings for Lua.
http://www.keplerproject.org/
http://luaforge.net/

Have a good selection of interesting Lua modules.
murgaLua uses this SQLite binding: http://luaforge.net/projects/luasqlite/

Juergen


RE: murgaLua CGI %ENV - dvw86 - 03-23-2008 10:40 AM

Thanks Juergen. If I get serious about it I may install another version of Lua but for just playing around murgaLua should work. It doesn't appear to put much of a load on my computer and is still fast. Your help was much appreciated Smile


RE: murgaLua CGI %ENV - JohnMurga - 03-23-2008 08:17 PM

Juergen Wrote:
But you shouldn't use murgaLua for CGI scripts. murgaLua is packed and has therefore more than an order of magnitude startup overhead (on my system it is more then 30x compared to stock lua5.1). Since there is nothing in murgaLua that isn't available elsewhere (except for the fltk bindings, which I guess you don't want to use in a CGI script ;-) there is no reason to use murgaLua for CGI scripts.

If you want to use it anyhow, it might make sense to unpack it (if the CGI script isn't only called once in a while) with "upx -d murgaLua". This way there is only a 8x startup overhead (on my system). Of course this applies to hot caches. With a cold cache the overhead might be smaller, due to the reduced binary size.


Not really a fair comparison as once you incorporate the relevant bindings to stock lua the startup time will increase too... Although if you are going to use murgaLua for CGI you probably should unpack it.

FYI, the XML bindings and a few other bits and pieces are also not available elsewhere ;-)

BTW, I'd like to see a test to prove your 30% file overhead claim from an earlier post.

Cheers
JohnM


RE: murgaLua CGI %ENV - dvw86 - 03-24-2008 03:39 AM

Ok tell me more about unpacking it. What will that do to the size? Since I am using it in Pupeee I am concerned about keeping it small. Also will that affect my other murgaLua scripts and applications? Good to see a new version out Smile


RE: murgaLua CGI %ENV - JohnMurga - 03-24-2008 04:04 AM

If you are using murgaLua for CGI then you invoke it each time a script is run, that means that you have to wait for it to start up ... And by default murgaLua is packed with UPX, which means that you have to wait a bit longer, as the executable itself is compressed and has to decompress.

As Juergen indicated you can use UPX to unpack it, and that should make it faster (although the executable will be well over twice the size).

One way around this would be to write a web-server in murgaLua capable of running murgaLua cgi scripts ... Either than the fact that script execution would be single threaded it would be pretty easy and avoid the startup issues mentioned here. Writing this web-server is on my todo list, as I'd like to include it in the murgaLua runtime.

Cheers
JohnM


RE: murgaLua CGI %ENV - dvw86 - 03-24-2008 06:29 AM

Thanks for the info John. I don't really notice any delay so I will leave it the way it is for now. Writing a web server in murgaLua sounds like a time consuming task.


RE: murgaLua CGI %ENV - asafp - 03-24-2008 06:55 AM

In my opinion, murgaLua has tremendous potential as a web scripting language. This is not really my area of expertise, but it seems that Perl and PHP dominate that realm mainly out of tradition. Those languages are certainly capable of powering some industrial strength applications, but I just don't like them (a topic for another post on another forum some other time). Some people don't even know that a web server application can be written in any programming language. Some web hosting companies restrict you to PHP and Perl.

Then there is ASP. I don't know much about it, but it seems like shooting an ant with an elephant gun.

Ruby on Rails might be on to something. I've always liked the concept of separating data storage, data presentation, and processing logic. The Rails model might be a good place to start for anyone looking to move murgaLua in this direction.

Just my two cents worth.


RE: murgaLua CGI %ENV - Juergen - 03-24-2008 06:57 AM

JohnMurga Wrote:
Not really a fair comparison as once you incorporate the relevant bindings to stock lua the startup time will increase too... Although if you are going to use murgaLua for CGI you probably should unpack it.

Would be interesting to measure it. But I guess it will still be a lot faster even when the sql bindings are loaded dynamically.

JohnMurga Wrote:
FYI, the XML bindings and a few other bits and pieces are also not available elsewhere ;-)

I know, but most functionality is available in another form on luaforge.

JohnMurga Wrote:
BTW, I'd like to see a test to prove your 30% file overhead claim from an earlier post.


Code:
unction iotest(filename, isize)
  local obytes=0
  local video=assert(io.open(filename,"r"),"Cant open file: "..filename)
  local devnull=assert(io.open("/dev/null","w"),"Cant open /dev/null")
  local size=video:seek("end")
  video:seek("set")

  local vs,pos,iterations
  iterations=size/isize

  while(iterations>=0) do
    vs=video:read(isize)
    devnull:write(vs)
    obytes=obytes+#vs
    iterations=iterations-1
  end
  video:close()
  return obytes
end
if type(arg[1])~="string" then print("You must prowide a filename as the first argument!") os.exit(1) else fn=arg[1]  end
if not arg[2] or not tonumber(arg[2]) then print("You must prvide a chunksize as the second argument!") os.exit(1) else cs=tonumber(arg[2]) end
print(iotest(fn,cs).." bytes written to /dev/null")


You should save that as io_speed.lua

and this:

Code:
#!/bin/bash
export TIMEFORMAT="%5R %5U %5S"
blocksize=${2:-10000}
filename=${1:?"The first parameter should be a large file! (additionally blocksize and runs could also be specified)"}
if ! [ -f $filename ] ; then echo "the file should exist!" ; exit -1 ; fi
runs=${3:-20}
offset=3 #to make sure the caches are warm
stock_lua=lua5.1
murgaLua=murgaLua
luascript=io_speed.lua
if ! [ -f $luascript ] ; then "where is the lua script?" ; exit -1 ; fi

function io_test () {
   local interp="$1"
   local pref="$2"
   shift 2
   local param="$@"
   for ((i=1;i<=runs;i++)) do
     echo run: $i with $interp $param
     tstring=$({ time $interp $param > /dev/null 2>&1 ; } 2>&1)
     set -- $(IFS=' ' ; echo $tstring)
     echo real: $1 user: $2 system: $3
     eval $pref\_real[$i]=$1
     eval $pref\_user[$i]=$2
     eval $pref\_system[$i]=$3
   done
}

function calculate_result() {
   local pref=$1
   result_real=0; result_system=0; result_user=0
   local real=$pref"_real" user=$pref"_user" system=$pref"_system"
   for ((i=$offset;i<=runs;i++)) do
     result_real=$(eval dc -e \"5 k $result_real \${$real[$i]} + p\")
     result_user=$(eval dc -e \"5 k $result_user \${$user[$i]} + p\")
     result_system=$(eval dc -e \"5 k $result_system \${$system[$i]} + p\")
   done
   result_real=$(eval dc -e \"5 k $result_real $runs $offset -  / p\")
   result_user=$(eval dc -e \"5 k $result_user $runs $offset -  / p\")
   result_system=$(eval dc -e \"5 k $result_system $runs $offset - / p\")
   eval $pref\_real[0]=$result_real
   eval $pref\_user[0]=$result_user
   eval $pref\_system[0]=$result_system
   echo real: $result_real user: $result_user system: $result_system
}
  
io_test $stock_lua "slo" "-e os.exit(0)"
calculate_result "slo"
io_test $murgaLua "mlo" "-e os.exit(0)"
calculate_result "mlo"
io_test $stock_lua "sl" $luascript $filename $blocksize
calculate_result "sl"
io_test $murgaLua "ml" $luascript $filename $blocksize
calculate_result "ml"
echo startup overhead: $(eval dc -e \"5 k ${mlo_real[0]} ${slo_real[0]} - p\")"s" which is a $(eval dc -e \"5 k ${mlo_real[0]} ${slo_real[0]} / p\") times overhead
echo average file copy time for stock lua is: ${sl_real[0]} and for murgaLua: ${ml_real[0]} which is a $(eval dc -e \"5 k ${ml_real[0]} ${mlo_real[0]} - ${sl_real[0]} ${slo_real[0]} - / 1 - 100 *p\") "% overhead"


as what you want.

The io_speed.lua is from an earlier experiment and copies a file to /dev/null (so it is Unix specific).

I also wrote a small bash script to test it out, because I found a kernel bug on my system when I tested it today. It should work on any linux system (if dc is installed).

Juergen


RE: murgaLua CGI %ENV - JohnMurga - 03-24-2008 07:11 AM

Juergen Wrote:
Would be interesting to measure it. But I guess it will still be a lot faster even when the sql bindings are loaded dynamically.

I am not entirely sure ...

Juergen Wrote:

JohnMurga Wrote:
FYI, the XML bindings and a few other bits and pieces are also not available elsewhere ;-)

I know, but most functionality is available in another form on luaforge.

Things that work and I have chosen to incorporate, yes ...
But most of the XML api is home grown as I didn't find something that did what I wanted.

Juergen Wrote:

JohnMurga Wrote:
BTW, I'd like to see a test to prove your 30% file overhead claim from an earlier post.

You should save that as io_speed.lua

Thanks !

That'll allow me to fine tune the build options and hopefully improve things.

Cheers
JohnM


RE: murgaLua CGI %ENV - Juergen - 03-25-2008 05:55 AM

JohnMurga Wrote:

Juergen Wrote:
Would be interesting to measure it. But I guess it will still be a lot faster even when the sql bindings are loaded dynamically.

I am not entirely sure ...

Actually 1ms is on a now common machine with 2GHz is about 2million CPU cycles. That is an awful lot of cycles to spend for a few thousand relocations. The Linux dynamic loader isn't that slow (actually it is quite fast). I did a short test and compiled a lsqulite3.so with the newest libsqlite (3.5.7) compiled in statically.
With the following test:

Code:
require"lsqlite3"
db = sqlite3.open('test.db')
os.exit(0)

It takes about 6ms to complete (an empty test.db exists afterward and I checked that indeed the library has been loaded successfully). Compared with the 4ms it takes to complete "lua -e "os.exit(0)" this is a 2ms overhead. (Of course everything with hot caches).
So main factor of the huge startup difference is UPX. On the machine I'm currently sitting, it takes about 210ms to start murgaLua packed compared with 40ms unpacked. But there is still a difference compared with 6ms.

JohnMurga Wrote:
Things that work and I have chosen to incorporate, yes ...
But most of the XML api is home grown as I didn't find something that did what I wanted.

There is also Michal Sweets mxml library which is also small and fast and it shouldn't be hard to write a binding if not already done.

JohnMurga Wrote:
That'll allow me to fine tune the build options and hopefully improve things.

Do you want to use selective optimization levels for some files?

Juergen


RE: murgaLua CGI %ENV - mikshaw - 04-12-2008 12:51 PM

I have a belief that a person can be too picky about web server performance if that server is on a personal machine and does not have much traffic. When you consider the fact that most people's machines are typically loaded with a lot of waste simply to run a desktop, and those same people often run their servers on a graphical system, the overhead of the gui crap they run greatly outweighs the performance difference between Lua and murgaLua.

I run a local server using murgaLua (still compressed) and its response is instant. If I were to run that same server on a ubuntu or windows system I wouldn't be surprised if Lua proper actually had lower performance than murgaLua does on my DSL/Slackware box.
That's just speculation, of course, but it's just to express my belief that a lot of people seem to put extra emphasis on slim applications while at the same time they are running fat operating systems.


RE: murgaLua CGI %ENV - JohnMurga - 04-14-2008 03:36 AM

There are many issues with murgaLua ...

The startup time is too high, and it is too big right now ...

Much of the startup time is murgaLua and LuaSocket initialization, however, I believe that for 0.7.X I can improve that dramatically (I have done a few tests), and I also think I can even get murgaLua small again ... Either way I had a self imposed ban on any new bindings after 0.6.X, so I guess I have gone a little crazy with that recently.

PS ... I have changed the build options for 0.6.8

Cheers
JohnM


RE: murgaLua CGI %ENV - Juergen - 04-15-2008 01:30 AM

JohnMurga Wrote:
There are many issues with murgaLua ...

The startup time is too high, and it is too big right now ...

Of course, this depends on personal perspective, but the startup time is really high. For the size, it shouldn't be a problem on normal users.
It would also make sense to document somewhere that it makes really sense to uncompress murgaLua, when the binary size doesn't matter.

JohnMurga Wrote:
Much of the startup time is murgaLua and LuaSocket initialization, however, I believe that for 0.7.X I can improve that dramatically (I have done a few tests), and I also think I can even get murgaLua small again ... Either way I had a self imposed ban on any new bindings after 0.6.X, so I guess I have gone a little crazy with that recently.

I think what would really make sense (although it is a little bit late) to do the initialization only when the functionality is required. (in this case the user has to use require() to initialize it)

JohnMurga Wrote:
PS ... I have changed the build options for 0.6.8

Yes, you exported the symbols (although I'm not sure if you got the order right (putting the -Wl,-E after the import of the static lua library). On the other hand this doesn't matter in this case at all, since you stripped them away anyhow. ;-)

Juergen


RE: murgaLua CGI %ENV - Juergen - 04-15-2008 02:27 AM

mikshaw Wrote:
I have a belief that a person can be too picky about web server performance if that server is on a personal machine and does not have much traffic. When you consider the fact that most people's machines are typically loaded with a lot of waste simply to run a desktop, and those same people often run their servers on a graphical system, the overhead of the gui crap they run greatly outweighs the performance difference between Lua and murgaLua.

I run a local server using murgaLua (still compressed) and its response is instant. If I were to run that same server on a ubuntu or windows system I wouldn't be surprised if Lua proper actually had lower performance than murgaLua does on my DSL/Slackware box.
That's just speculation, of course, but it's just to express my belief that a lot of people seem to put extra emphasis on slim applications while at the same time they are running fat operating systems.

Don't overestimate the desktop overhead. The biggest overhead is memory wise. But if everything is done right (there is still a lot of software out there that does ridiculus things, like waking up every few 100 us to check someting which could be better done using the right mechanisms), there shouldn't be that much overhead, except for the memory usage. The most overhead on the desktop, which I experience on my machines, is when I browse and hit a web site which shows a dozen or more flash animations. Unfortunately that can even max out a fast machine.

And yes, if you write something with a web GUI that spawns off a murgaLua CGI once in a while, you will hardly observe a speed problem. But if you use it for a site which is used by a few users concurrently and some web pages call multible CGI scripts, 100ms startup overhead leads pretty fast to big trouble.

On the other hand, while UPX packing makes murgaLua much smaller (and hides the real size), this benefit only matters when you have very limited space on your storage medium. In any other case it is very counter productive, because it will cost you a lot of memory if multiple copies of murgaLua run concurrently, because page sharing and demand paging obviously doesn't work with UPX compressed binaries.
So if you have say 5 instances of murgaLua running, the difference is (roughly estimated for the dynamic binary) more than 7Mb in memory consumption.

Juergen


RE: murgaLua CGI %ENV - JohnMurga - 04-15-2008 04:17 AM

Juergen Wrote:
So if you have say 5 instances of murgaLua running, the difference is (roughly estimated for the dynamic binary) more than 7Mb in memory consumption.

Not that most people would notice 7Mb, however, the way to do it right would be to have a murgaLua server that can service those 5 concurrent users in separate threads. Having a thread pool and a compiled GCI lua cache then would get rid of most of the overhead and give you a very optimized experience ... I believe that writing a basic web server along these lines won't be hard, so I'll give it a go.

Anyway ...

My focus from now on is performance, size and more FLTK bug fixes and features.

Juergen, I could really do with your feedback on the luasys functionality and some of the other stuff in 0.6.8 ...

Cheers
JohnM


RE: murgaLua CGI %ENV - JohnMurga - 04-15-2008 07:28 AM

Juergen Wrote:
Yes, you exported the symbols (although I'm not sure if you got the order right (putting the -Wl,-E after the import of the static lua library). On the other hand this doesn't matter in this case at all, since you stripped them away anyhow. ;-)

That is not what I was referring to ...

If you try third party modules with the new executable you may find it no longer segfaults on you.

Cheers
JohnM


RE: murgaLua CGI %ENV - dvw86 - 05-20-2012 02:45 AM

It's been a long time but I have still been playing with this. I have a web based application that is using murgaLua. My wife has been using it frequently for her volunteer work for about a year now, and it has done very well. I tried just using Lua and adding the in the needed modules, but I found that I was basically building murgaLua. It is designed to run on a stand alone machine and only listen to the loopback. Doing it this way, performance has been great. In Windows XP and Windows 7 I am using the Mongoose web server. In Mac OSX and Ubuntu I am using Apache. Both work very well with no difference to the user. I am now starting to get some interest in my application at a corporate level and I was hoping that interest in murgaLua hasn't died. I'm sure that a lot has gone on in everyone's lives since I was last on here. I hope all is well.


RE: murgaLua CGI %ENV - JohnMurga - 05-28-2012 04:51 AM

I am still here ...

Although I have been having a crazy time at work.

The last build in December may have had an embedded web-server (my current one does anyway).

I hope to tidy things up in the next couple of weeks and make another release. Other than web stuff I have added some SqLite utilities and multi-processing stuff.

Cheers
JohnM


RE: murgaLua CGI %ENV - jpjacobs - 05-28-2012 07:35 AM

Nice to hear! I'm looking forward to testing it Smile!

Kind regards,

Jan-Pieter


RE: murgaLua CGI %ENV - dvw86 - 05-29-2012 01:55 AM

That sounds great. It was a bit of a challenge to get all the web server details worked out, so an embedded one would be fantastic. I am looking forward to it.


RE: murgaLua CGI %ENV - JohnMurga - 05-30-2012 08:52 PM

dvw86 Wrote:
That sounds great. It was a bit of a challenge to get all the web server details worked out, so an embedded one would be fantastic. I am looking forward to it.

It's actually been there for months :-)

If you look at the RC build here :
http://murga-projects.com/forum/showthread.php?tid=418

You'll find a text web-server using the API in tests/http/example.lua

I guess I should have made a bigger deal of that :-)

Cheers
JohnM


RE: murgaLua CGI %ENV - dvw86 - 06-02-2012 12:27 PM

Thanks,
I just got back from vacation and saw the last post. I will download it and give it a try.


RE: murgaLua CGI %ENV - dvw86 - 06-02-2012 12:50 PM

Okay, I have a few questions off hand.

Here are the first few lines of the example.

Code:
#!/usr/bin/lua

local ctx = mg.start{
    document_root = "./bindings/lua",

    cgi_extensions = "lua",
    cgi_interpreter = "/usr/bin/lua",


It looks like you are using Lua (not murgaLua?) and then you are starting the Mongoose web server and then you configure the web server settings. But again you are using lua instead of murgaLua. Are you re-naming murgaLua as "/usr/bin/lua"?

Here is what my Mongoose configuration file looks like when I use it on Windows with murgaLua as the cgi interpreter. I imagine that I could make the access_control_list a variable as well.

Code:
cgi_interpreter      D:\windows\lua\murgaLua
cgi_extensions    .lua
document_root      D:\http-root
access_control_list      -0.0.0.0/0,+127.0.0.1




RE: murgaLua CGI %ENV - JohnMurga - 06-02-2012 04:46 PM

dvw86 Wrote:
It looks like you are using Lua (not murgaLua?) and then you are starting the Mongoose web server and then you configure the web server settings. But again you are using lua instead of murgaLua. Are you re-naming murgaLua as "/usr/bin/lua"?

The sad an honest response is that I did not test CGI ...

As I was interested in dealing with requests in-process.

As murgaLua is running Mongoose itself it can service the requests itself through callbacks. This means that it doesn't have to spawn a process each time and is much faster.

If you do want to use the CGI interpreter I suspect that line should read :

Code:
cgi_interpreter = murgaLua_ExePath,

I would appreciate some examples if you play with this :-)

dvw86 Wrote:
Here is what my Mongoose configuration file looks like when I use it on Windows with murgaLua as the cgi interpreter. I imagine that I could make the access_control_list a variable as well.

Yes you can ...

In fact, here are the one you can set all of the following (I don't think num_threads will work though) :

Code:
cgi_extensions
cgi_environment
put_delete_passwords_file
cgi_interpreter
protect_uri
authentication_domain
ssi_extensions
access_log_file
ssl_chain_file
enable_directory_listing
error_log_file
global_passwords_file
index_files
enable_keep_alive
access_control_list
max_request_size
extra_mime_types
listening_ports
document_root
ssl_certificate
num_threads
run_as_user




RE: murgaLua CGI %ENV - dvw86 - 06-03-2012 04:48 AM

Okay, that makes more sense. I would be happy to make up some examples and send them to you once it is working. I still am having issues though. Perhaps I am simply using it incorrectly. What I would like to do is have the user click on the lua file and have it start the web server, configure the web server and then launch a web browser pointing at the same script. I may need two scripts (one to launch web server and one to run the app), but wouldn't that launch two instances of murgaLua?

What I am currently doing is to have the web server always running as a stand alone process. The user simply points their web browser at the lua file and the app then runs in the web browser.


RE: murgaLua CGI %ENV - dvw86 - 06-03-2012 05:13 AM

I'm not sure if this would help or not. This is a VB script I wrote but do not use. It uses QTWeb, Mongoose and murgaLua. I had the QTWeb home page set to the lua script that I wanted to run. It gave the functionality that I was looking for, but my wife wanted to use a Mac and I didn't want to re-write it. My goal would be to have this functionality all into one lua file along with the lua application that runs in the web browser.

Code:
Set WshShell = CreateObject("WScript.Shell")
'WScript.Echo WshShell.CurrentDirectory

'Find where this script is located.
Dim here
here = WshShell.CurrentDirectory

'Define where mongoose is.
Dim mongoose
mongoose = here & "\mongoose\mongoose"

'Define where the mongoose configuration file is.
Dim mongooseConf
mongooseConf = here & "\mongoose\mongoose.conf"

'Define the cgi_interpreter for the mongoose configuration file.
Dim cgi_interpreter
cgi_interpreter = "cgi_interpreter      " & here & "\lua\murgaLua"

'Define the cgi_extensions for the mongoose configuration file.
Dim cgi_extensions
cgi_extensions = "cgi_extensions    .lua"

'Define the path minus the windows directory.
Dim up
up = split(here,"windows")

Dim up1    
up1 = up(0)

'Define the document_root for the mongoose configuration file.
Dim document_root
document_root = "document_root      " + up1 + "views"

'Define the access_control_list for the mongoose configuration file.
Dim access_control_list
access_control_list = "access_control_list      -0.0.0.0/0,+127.0.0.1"

'Define QtWeb.
Dim QtWeb
QtWeb = here & "\qtweb\QtWeb.exe"

'See what programs are running.
Set colProcessList = GetObject("Winmgmts:").ExecQuery ("Select * from Win32_Process")

'Loop though the list and see if mongoose is there.
For Each objProcess in colProcessList

'If mongoose is running mark it as true.
If objProcess.name = "MONGOOSE.EXE" then
    mongooseFound = True
    
    'This is in case mongoose.exe is in lowercase.
    ElseIF objProcess.name = "mongoose.exe" then
    mongooseFound = True
End if
Next
    
'If mongoose is running.
If mongooseFound = True then
        
'Let the user know that mongoose is already running.    
    'Msgbox("Mongoose is already running.")
        
    'Start QtWeb.
    Set WshShell = CreateObject("WScript.Shell")
    WshShell.Run chr(34) & QtWeb & Chr(34), 0
    Set WshShell = Nothing
    
    'If mongoose is not already running.
    Else

    'Write the mongoose.conf file.
    Dim filesys, filetxt, getname, path
    Set filesys = CreateObject("Scripting.FileSystemObject")
    Set filetxt = filesys.CreateTextFile(mongooseConf, True)
    path = filesys.GetAbsolutePathName(mongooseConf)
    getname = filesys.GetFileName(path)
    filetxt.WriteLine(cgi_interpreter)
    filetxt.WriteLine(cgi_extensions)
    filetxt.WriteLine(document_root)
    filetxt.WriteLine(access_control_list)
    filetxt.Close

    'If the mongoose.conf file was created.
    If filesys.FileExists(path) Then
        'WScript.Echo ("Your file, '" & getname & "', has been created.")
  
        'Start mongoose
        Set WshShell = CreateObject("WScript.Shell")
        WshShell.Run chr(34) & mongoose & Chr(34), 0
        Set WshShell = Nothing
    End If  

'See what programs are running now.
Set colProcessList = GetObject("Winmgmts:").ExecQuery ("Select * from Win32_Process")
    
'Loop though the list again and see if mongoose is there.
For Each objProcess in colProcessList

' Unhide this to see a list of each process.
'Msgbox(objProcess.name)

'If mongoose is running mark it as true.
If objProcess.name = "MONGOOSE.EXE" then
    mongooseFound1 = True
    
    'This is in case mongoose.exe is in lowercase.
    ElseIF objProcess.name = "mongoose.exe" then
    mongooseFound1 = True
    
End if
Next    
    
'If mongoose is running.
If mongooseFound1 = True then
        
    'Let the user know that mongoose is running.    
    'Msgbox("Mongoose is now running.")
        
    'Start QtWeb.
    Set WshShell = CreateObject("WScript.Shell")
    WshShell.Run chr(34) & QtWeb & Chr(34), 0
    Set WshShell = Nothing

    'Run this check as long as mongoose or QtWeb is running.
    While 0 = 0
    
    'Define mongooseFound2 and set it as false.    
    mongooseFound2 = False
    
    'Define QtWebFound and set it as false.
    QtWebFound = False
    
    'Set a 2 second delay between checks.
    Set WshShell = CreateObject("WScript.Shell")
    wscript.sleep 2000
    
    'See what programs are running now.
    Set colProcessList = GetObject("Winmgmts:").ExecQuery ("Select * from Win32_Process")
    
    'Loop though the list and see what is there.
    For Each objProcess in colProcessList

    'If mongoose is running mark it as true.
    If objProcess.name = "MONGOOSE.EXE" then
    mongooseFound2 = True
    
        'This is in case mongoose.exe is in lowercase.
        ElseIF objProcess.name = "mongoose.exe" then
        mongooseFound2 = True
    
        'If QtWeb is running mark it as true.
        ElseIf objProcess.name = "QtWeb.exe" Then    
        
        QtWebFound = True
        
    End If
    Next    
    
    'If mongoose was killed, then kill QtWeb.
    If mongooseFound2 = False Then
    
        'Let the user know that this app is about to stop.
        Msgbox("Stopping Mongoose will kill this application!")
    
        'Open up a shell and kill QtWeb.
        WshShell.Run ("C:\Windows\system32\cmd.exe")
        ' I added sleep  to fix a problem
        wscript.sleep 50
        WshShell.sendkeys "taskkill /IM QtWeb.exe"
        wscript.sleep 50
        WshShell.SendKeys "{ENTER}"
    
        'Now kill the shell.
        wscript.sleep 50
        WshShell.sendkeys "taskkill /IM cmd.exe"
        wscript.sleep 50
        WshShell.SendKeys "{ENTER}"
    
        'Exit from the VB Script.
        WScript.Quit [exitcode]
    
        'If mongoose is running but QtWeb has been killed, stop mongoose.
    ElseIf QtWebFound = False Then
    
        'Msgbox("QtWeb has been Stoped!")
        
        'Open up a shell and kill mongoose.
        WshShell.Run ("C:\Windows\system32\cmd.exe")
        ' I Add sleep  to fix the problem :d
        wscript.sleep 50
        WshShell.sendkeys "taskkill /F /IM mongoose.exe"
        wscript.sleep 50
        WshShell.SendKeys "{ENTER}"
        wscript.sleep 50
        WshShell.sendkeys "taskkill /F /IM MONGOOSE.EXE"
        wscript.sleep 50
        WshShell.SendKeys "{ENTER}"
        
        'Now kill the sell.
        wscript.sleep 50
        WshShell.sendkeys "taskkill /IM cmd.exe"
        wscript.sleep 50
        WshShell.SendKeys "{ENTER}"
    
        'Exit from the VB Script.
        WScript.Quit [exitcode]
    
    End If

    Set WshShell = Nothing

    Wend
        
    'If mongoose did not start.
Else    
    
    Msgbox("Could not start Mongoose.")

    'End if mongoose is running (second check).     
End If    
    
'End if mongoose is running (first check).
End If