I am looking for a package containig Apache Web server, PostgreSQL database and Perl for Windows (7, 10). Does anybody know such a package, possibly portable?
I don't believe so, but those sorts of bundles are not as necessary as they once were. They're no longer as wielded together. Instead, get the pieces.
Strawberry Perl which comes with PostgreSQL drivers and compilers and everything you need for Perl development.
PostgreSQL for Windows
Apache for Windows
I'd recommend skipping Apache unless you specifically need it, it's likely quite a bit more complex than you need. Instead, write web server generic code using Plack. Use a Perl web server for development, and then the application can be deployed to whatever web server you'd like for production. Using a Perl web framework such as Dancer will make that all much simpler.
I have a site in ASP that I want to convert to a language that I can host on my Mac (I haven't found a practical way to host Classic ASP). The site connects to a MySQL database to pull data which is represented using Google Charts in a Dashboard.
I don't have experience with many other scripting languages, but am willing to learn. It seems that Web.py would be the easiest. Any suggestions?
I know it's a late answer but this caught my eye. Last year I moved a very complex aplication from ASP.NET to run on unix using the Mono framework.
I found Mono and the MonoDevelop editor to be solid tools, and had no problems running my code natively on linux and osx.
Now you're talking about classic ASP. Mono does have the opensource "xsp" and "xsp2" web servers built in... I believe xsp can handle classic ASP.
Using Mono bought us the 12 weeks I needed to go heads down and convert the entire application to Python using web.py. I agree it's a great framework, especially if you want a lot of control and not be bound by a templating based system like Django.
Regarding Stare's comment... if you do virtualization I'd strongly recommend VirtualBox. Parallels has burned all their bridges with me.
I would advice you to use a virtualization software on your mac to run an IIS (like VMware Fusion or Parallels). The you could easily develop ASP on your MAC.
Thats what I'm doing (Even .NET with Visual Studio) and it has been the best investment ever!
I would like to run a Perl web application on Windows (assume 2008 R2 x64) with reasonable speed / capacity.
Currently my app is based on Mojolicious, using Strawberry Perl and running as CGI through Apache 2.2-win32. With about 20000 lines of code, the creation of the perl process takes a lot of time, almost a second or two while the actually processing is just a blink of a second.
I would imagine it to be running much faster and be able to serve much more req/sec if the app is configured in a Fast CGI or persistent style.
If I am on Linux, I would probably have sticked with the PSGI/Plack/Starman and Nginx reverse proxying.
Unfortunately, Starman/Starlet does not support Win32.
Morbo/Twiggy does not meet my need because the webapp does block (DB calls) and for some request it does take a while to finish.
So I am looking at Fast CGI solution right now. Unfortunately Apache and mod_fcgid does not work with Perl (Stackoverflow). And I am yet be able to found or work out a compatible binary with mod_fastcgi with 2.4. Something I didn't try yet is mod_fastcgi + Apache 2.2, but I wish I could stay on Apache 2.4.
I am also thinking if I could run my own FCGI process manager (the thing that manage preforking), together with Mojo::Server::FastCGI, and use mod_proxy_fcgi to do reverse proxy instead. Perl module FCGI::ProcManager also does not support Win32. Could there be any other process manager, prehaps in C#? (Preferably in C# for further hacking)
Let me sum up the question -
What's the best way to run Perl web app on Windows at a speed much faster than CGI, but not in non-blocking style.
and prehaps that lead to a question of - how to make mod_fcgid works with Perl? Or is there any fcgi process manager out there?
you could use Mojolicious + mod_psgi + apache.
There are pre-compiled binaries here, although for Apache 2.2:
http://strawberryperl.com/package/kmx/mod_psgi/
--
Mike
You could use the threaded Plack server Thrall.
Is Cygwin considered robust and safe enough to be used on enterprise applications?
Do you know Enterprise applications that were developed or using Cygwin?
If you've been using cygwin - how often did you need support? Is there a fine-support for Cygwin? how well was the support you were given?
Thank you very much.
Why on earth would you even consider cygwin towards any sort of enterprise application? Even their site directly gives multiple signs it shouldn't be used for anything critical. You can't run native linux apps and you have to rebuild your app from source if you want it to run. It won't make your apps able to use any *nix functionality like signals, ptys, etc. All it is is a slim Linux type API layer....to answer your question, I don't think anyone would want to use cygwin in an enterprise application.
Like Maz asked, why wouldn't you just run linux? What potential benefits would you ever see coming from cygwin in an enterprise environment?
The best answer to your question may be obtained from the Cygwin web site. The answers obtained there come directly from the maintainers of the Cygwin DLL and ported software.
I'm trying/thinking of making CppCMS - C++ Web Framework project little bit more cross platform.
Today I can easily support Linux, OpenSolaris, FreeBSD and even Cygwin. But when it comes to Native Windows it becomes really painful:
The overview of the situation:
I'm POSIX/Linux developer and I'm barely familiar with Native Windows development tools like Visual Studio and Win32 API. However I do some work for this platform so I understand the limitations and the fact that Windows is totally different world.
This is web project that uses APIs that popular in Unix world, like: CGI, FastCGI and SCGI that implemented in most UNIX web servers; but I understand that I would not be able to use it with IIS because it does not support FastCGI over TCP/IP (only Windows pipes).
So even when it would work it would probably run only with Windows port of Apache.
I relay heavily on POSIX API:
Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
I use some file-locking facilities (but I can probably give them up without forking)
I have intensive use of native pthreads, even I can replace them with Boost.Thread
I probably would never be able to support Visual Studio (maybe 2010 with C++0x support), because I relay on C++0x decltype/auto feature or typeof/__typeof__ extension that is supported by most compilers I worked with: gcc, intel, sun studio. (To be honest: I can work without them but it makes the life much easier to framework user.
I relay heavily on autotools and I can't replace them with CMake, bjam or friends, because when it comes to support of internationalization, cross copiling, package management, they just does not give me a solution.
There are many annoying points like missing gmtime_r, or localtime_r under windows and many others that just require from me to rewrite them or replace them with 3rd part libraries.
There are still many "UNIX like" libraries that ported to Win32 like: iconv, gcrypt and some others that are barely ported like libdbi that have many limitations on windows.
Bottom line:
There is lots of non-trivial work to do, and even when it would be complete, it would probably work only with MingW tools and not "native" tools that Windows programmers are
familiar with.
So, my questions are:
Does such MingW port worth an effort? Would this help to build bigger community?
Does anybody have experience on how painful porting big projects from POSIX environment to
Win32 API is?
Would it be useful for Windows developers at all?
Edit:
It is also important for me to understand, how many of windows developers prefer to use
Open source development tools, MingW over Microsoft development solutions like VS.
Edit #2: Clearification about "native" windows solusions and IIS.
In fact, running framework with IIS is really hard problem. I explain:
The project relates to standard web server API as FastCGI or SCGI that allows to accept many requests over sinlge socket. Thus, on application side, I accept new request proceed it and returns the answer. Sometimes several threads process several requests.
Thus, implementing one or two standard protocols I open communication with any existing server: Apache, lighttpd, nginx, cherokee... or any other servers; with small exception of IIS
IIS has implementation of FastCGI, but... It supports only 1 connection per local process only that controlled by web server...
So... there is absolutely no standard way to connect my application to IIS.
Please note, I implement standard Web server API, I do not implement Neither IIS proprietary ISAPI nor Apache proprietary API, even the second is more important as for targeting UNIX world.
So, just Windows IIS Web world is just not really ready for cooperation for such project, so if anybody would use it under Windows it would use it with more open web servers.
You should base your decision on user demand. Have users ever requested using the framework on Windows? If so, did they explain why they wanted to use Windows (e.g. what additional constraints they had, what webserver they wanted to use, etc.)?
Typically, Windows users do expect that things work the Windows way. That means Visual Studio support, IIS support, MSI installer, and so on. If something still feels like being Unix, I would rather use Unix proper, instead of fighting with a half-working port.
As a windows client app developer it sort of hurts me that the development environment division currently is essentially Win32 and everything else and that they are mostly incompatible. That's why I'm preparing to move to MinGW for my personal windows app projects and to try to make them cross-platform.
I would suggest gradually moving to more cross-platform libraries like, as you suggested, refactoring pthreads to boost::thread, or going from fork() to multi-process with IPC, probably also using boost's facilities. Date/time stuff can be dealt with Boost libs as well. As for database support, there are
Microsoft compiler support is not that important I think, as MinGW provides a decent build environment with all the IDEs that support it, Eclipse CDT and Dev-C++ being among the most popular. But if you are going to make your project msvc-compatible, make sure users will be able to use Express editions of Visual Studio 2010 (as soon as thay come out) - that way no one will have to fork out for a Visual Studio 2010 (upgrade) just to use your project and there will be no problem for you to require the latest in Microsoft technology.
Most likely you won't avoid some amount of ifdefs for a code base of your project's size, but surely the effort might be worth it, if not only for gaining valuable experience and expanding the community with a few new happy and grateful members.
Your saying that you can support Cygwin quite easily reminds me that I've seen commercial Windows software that simply bundled in cygwin1.dll to support some originally-Unix code. If adding cygwin1.dll to your installer is all it takes, try it out.
I think you only have to look at the questions asked on SO to work out that MinGW users on Windows (of which I am one) are in a minority in the development community - the vast majority of Windows developers are using MS tools. Anyway, the compiler is only half (or less) of the issue - if your architecture depends on forking lots of processes, using MinGW is not going to help you. My advice is, if you really want to do cross platform development:
look at how Apache do it
consider using the Apache libraries as your base
don't use very new or compiler-specific language features
use multi-threading rather than multi-process
Does such MingW port worth an effort? Would this help to build bigger community?
I am still working myself on this issue with my own large POSIX project and my conclusion is that if you need to later interface with Microsoft products, then its worth while, however then I would only use MingW if project is medium small, if it is very large, then I would go all the way with MSDN Microsoft development tools - Huge amount of help will be available there - however it will cost
Does anybody have experience on how painful porting big projects from POSIX environment to Win32 API is?
sofar my own conversion of my POSIX project have been constantly put on hold, because of the amount of time each issue takes to handle is enormous - not finished converting yet - If I ever will be
Would it be useful for Windows developers at all?
Sure working inside the Microsoft IDE using tools from MSDN will definately decrease development time, however it will increase your dependence on Microsoft libraries - something you need to decide from beginning if that is an issue
**
Actually you could just add the necessary cygwin dlls to your projects make and then you would beable to run it in windows
I managed to make my POSIX project run when I added following dlls
cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll
Probably your project will have different dependencies, however if you think conversion is not worth it, then perhaps this is a solution for you
You could also add your libs as static, then you would end up with only having to provide the last cygwin1.dll