Forum OpenACS Q&A: Windows Installer ready with OpenACS, dotLrn and Project/Open


proudly announcing the availability of our first Windows 2000/XP/2003 installer. Just click on the "Next" button five times and you've got OpenACS running in less then 10 minutes.

The installer is based on the incredible work from Vlassis, but uses Inno Setup (freeware) instead of Install Anywhere. Also, the installer handles uninstalls and has some further extensions.

It contains PostgreSQL on Cygwin, AOLServer 4.0.beta10, dotLrn 2.0.3, Project/Open and its own source code (GPLed). The installation time on Windows is < 10 min (until the "OpenACS Installation" screen).

We have tested the P/O part on some 5 different computers already and we haven't had any problems, except when either IIS or CygWin were installed before. However, we haven't checked the dotLrn part too much in detail.

You can download the installer together with our first user guides and the binary Linux installer at

Our roadmap for the next weeks includes:

- Setting up sample consulting and translation companies for Project/Consulting and Project/Translation.
- Fixing Bugs
- Improving the user guides
- Creating a P/O documentation package
- Creating a context sensitive help system (any ideas?)

Have you heard anything about a a dotLrn preconfiguration? I'm refering to a PostgreSQL database dump or something similar that could be loaded during installation time in order to provide occasional users with the experience how dotLrn could be used in a real organization?



Hey Frank, we need to coordinate this effort, we plan to maintain this code, while making improvements and make it a general installer for windows & linux for next upcomming releases, one of the first steps is to have this code on the oacs repository, and then have customized version for openacs & .LRN.
Frank, Great work!
Great. Just a short question. What were your reason that you decided for Inno Setup? I mean what are the main differences?
Whoever is maintaining this code, can you make the sources for creating the installer available as well, so all of us could make custom versions of the installation and help with keeping the sources up to date?

First of all, please take note that most of the effort has been done by Vlassis Rizopoulos, because he found out how to install CygWin on Windows without the CygWin installer and how to start and install the PostgreSQL database using CygWin. So he is the guy who deserves most of the attention. We just took his "installation script" and ported it to a free Windows installer.

Vlassis, what do you think, how do you want to proceed?

Concerning our (Project/Open) part: We are going to maintain and extend this installer atleast for our own purposes, because it forms the core of our sales strategy towards our "less sophisticated" customers in the Translation industry.

> we need to coordinate this effort

We would be extremely happy to share the development effort with the dotLrn organization or anybody else (Hi Mike!). Just the testing of the current installer has taken us nearly a week... So maybe there is an interesting option for the dotLrn organization and Project/Open to collaborate. Please let us know. We have included the dotLrn stuff, but we haven't dedicated much time on testing here.

> What were your reason that you decided for Inno Setup?

We have lost a lot of time playing around with WIX (nice but rather complicated), Install Anywhere and NSIS before. Jamie gave us the hint about Inno Setup. It just worked, it provides "Component selection" and it is easy to customize using Pascal scripting.

> can you make the sources [...] available

The installer includes its own sources. They are GPLed, so it should be easy from a technial point to exclude the Project/Open components. Please select the checkbox in the "Component select screen" at the very bottom. You will need Perl and some some ZIP files with contents though. Check Vlassis installer for reference.



Rocael Hernandez wrote:
> have customized version for openacs & .LRN

I've checked this option a bit more in detail this weekend and I've seen that Inno Setup supports #if - #else preprocessor statements similar to C. This means that we could have a single installer source code that generates installers for dotLrn or Project/Open. I'll try this in the next version of the installer.


It contains PostgreSQL on Cygwin, AOLServer 4.0.beta10, dotLrn 2.0.3, Project/Open and its own source code (GPLed). The installation time on Windows is < 10 min (until the "OpenACS Installation" screen).

I'd really like to see that contain AOLserver 4.0.9 -- there have been a large number of bug fixes in AOLserver since 4.0b10. :-)

-- Dossy

Hi Dossy,

Incredible work you're doing with AOLserver...

We tried with 4.0.9b, but compiling all of these additional modules is a terrible hassle for somebody not in M$. We've tried with Jamies AOLServer 4.1.0 alpha, but there were several issues and we finally gave up:

But maybe together it could work out: We would love to include the new version if somebody could test that the combination works out. It's just that we already lost about two weeks with these issues, and our "key competences" are not with M$ but in building user-friendly GUI stuff...

So why don't you install OpenACS & P/O (P/O is really just some 8 OpenACS modules), replace 4.0.beta10 by 4.0.9, check that it installs correctly, and send us the binary to include?


Frank, presumably because Dossy is busy doing other higher priority things? I'd say installing all of OpenACS and Project Open on Windows, just to check whether they actually work with the latest AOLserver code is, uh, more a job for the OpenACS and Project Open developers, and/or the auto-magic Windows Insaller maintainer, than it is for the AOLserver maintainer.

More importantly, any "Windows Installer" is doomed to be eternally out of date - and thus not particularly useful - until and unless the AOLserver build process on Windows (the lack there of!) is dramatically improved. Right now, building both the core and a bunch of modules on Unix is fairly easy, but building on Windows has only very limited support and is thus a major PITA. (Which is still a lot better than it used to be, note. Dossy's Windows Tcl build script for the AOLserver core is a very useful prototype.)

Creating a spiffy Windows installer using years-old binaries, but having no useful way to update and recompile all that code, seems very much putting the cart before the horse...

One of these days I may work on such a Windows build process, (likely experimenting with "bras", the Tcl-based make replacement), but as I currently only use the AOLserver core plus nsopenssl on Windows, I don't have any immediate plans to do so. And maybe Dossy or someone else will beat me to it.

If all you want is recent Windows binaries for Tcl, the AOLserver core, or nsopenssl, I can just send you those. I'm currently using slightly out of date versions of everything (Tcl 8.4.7, AOLserver 4.0.8, and nsopenssl 3.0 beta 23), but I'll probably be upgrading to the latest releases of everything in a few weeks.

Hi Andrew,

thanks for the reply.

> installing all of OpenACS and Project Open on Windows,
> just to check whether they actually work

It's the oposite way from our (P/O) perspective: OpenACS inc. PostgreSQL is installed in <10 minutes, so that really shouldn't be an important effort for anybody. I'm only talking about OpenACS. P/O's requirements are uncritical.

The benefit of such an installation is that the AOLServer developers would get an integrated testing environment. They wouldn't have to rely on other persons to report errors but simpley would need to start the OpenACS _installation_ procedure to get a 70% test coverage.

The errors that stopped us were really basic and could probably be resolved by an AOLServer developer probably within minutes.

Concerning the build process: This was a _real_ pain for us. 4.0.beta10 is working more or less satisfactory for us, imagine..., so we're never going to touch this anymore.

I believe that OpenACS + AOLServer has a _huge_ (OSS-) market potential if it would be easier to install, particularly on Win32. But our organizational issues have inhibited this already since several years. Maybe we can finally break this ice.

> any "Windows Installer" is doomed to be eternally
> out of date

There is one fact that is probably difficult to swallow for a developer: That even an old version of AOLServer is doing the job. We're still using 3.3oacs on our Linux production environments and I've got _no_ intention to change until I see a major benefit. And a similar situation holds for Win32 with the addition that binary releases are easier on Win32 then on Linux because of a more coherent system environment.

So I would disagree with you on this point. Being "out of date" is not even relevant from a users point of view. AOLServer is very stable in general so a new binary "dumb-user" release every 6 months would be more then sufficient...

However disagreeing, we all have the same objective: Promoting AOLServer + Openacs.