Using Cygwin on enterprise-class applications - windows

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.

Related

Are there any plans for a native windows version of NodeJs?

I'm wondering if anyone has any information or speculation as to when or if there will be a native windows version/port of Node.js.
There is an ongoing effort to provide a mingw port of Node.js. Version 0.3.6+ can be build that way.
However that is still experimental and anything but ready for more than quick and dirty development. Even in case this version matures, I suppose that it will always lag behind the *nix versions, mainly due to the fact that the event loop implementations that Node uses were originally written for those systems and APIs.
The windows version may become stable for development at some point in the future, but I hardly doubt it will ever be usable for production.
July 2011 Update:
#nodejs v0.5.1 is the first to ship with an official Windows executable. We're hoping to get some good feedback.
Microsoft has officially gotten involved with joyent in making node.js work natively on windows.
If one or two Windows C++ developers would put in the effort, then they could fill the gaps in the native Windows version and produce a node.js implementation that would be usable for production.
For now, there is a working Cygwin version and I don't know of any testing that shows it to be unsuitable for production. It certainly works fine (version 0.5.0pre) for development.
Have a look at:
http://www.rafaljonca.org/d/nodejs-windows
Which is based on the work of these guys here
http://node-js.prcn.co.cc/
Both good ways of getting node on windows if you dont have cygwin. However after many heartaches I found developing Node stuff on windows easiest by just using virtualbox with the ubuntu image.
Tnx
GT
I am strictly a Windows Dev and I have wanted to mess around with Node.js for quite a while.
It looks like Microsoft, Rackspace.com and the Node.js team are planning on working together port Node.js to Windows.
So, it's not hear yet but it should be soon. w00t!
The Official Node.js Blog
The first stable version has been released: Release details here.
Be sure to check for the latest version as the link above will go out of date.

Development Environment in Windows [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What are your recommendations for setting up a development environment in Windows, especially when not using an IDE. I am attempting to familiarize myself with Windows, and I feel a bit lost. What do developers commonly work on, especially when developing in multiple languages (e.g. Java, Python, C) in the same time.
So far, I have been a hardline using Mac+Linux environments where I love my command line a lot. I pretty much run all my compilations, testing, code repository commands in the terminal and have multiple terminals all the time. Terminal features (e.g. integrated bash completion, easy copy&paste, easy to setup environment variables) and package management tools (e.g. apt-get, port, fink) are quite handy. I dislike hunting down different websites to install their latest binary build.
Coming back to my question. My question is two fold:
What's commonly used? Do developers on Windows commonly use command line, or just be satisfied with an IDE?
For comers from Linux/Mac world: what do you recommend to get up to speed?
NOTE: I realize that a lot of Windows developers haven't used Linux, so they may not know what I'm talking about when it comes to Linux environment.
It's almost unheard of to not use an IDE for Windows development.
I started programming in the early 80's so grew up on the command line, but nothing beats a modern IDE for productivity.
By far the most common choice is Visual Studio, though I have also used #develop (open source) and find it a fine platform to get up to speed with.
I have used Eclipse extensively (on Linux and Windows) and find Visual Studio to be easier to use. I especially miss options for debugging under windows such as moving the instruction pointer around during debug and change-and-continue (change the code, within limits, while debugging, move the instruction pointer back if necessary, and keep debugging).
If you have used Eclipse, Visual Studio or #develop will not be that hard to get used to.
I tend to install cygwin, which is a unix emulation layer and includes many of the standard unix utilities (grep, awk, sed, etc). You can use bash or any other unix shell with cygwin to basically give yourself a unix environment on windows.
There are some downsides, paths are a good example. Windows programs expect windows paths while the unix tools expect unix paths. You can convert between the two using the cygpath program, but sometimes its tricky to know when to use it.
Another thing I do fairly often is create a bunch of batch files that load different programs onto my path. This allows me to have different version of say java installed and I can pick the version I want to use for any given shell session. I link a bunch of these together so that I have a full environment for the program I'm working on. For example, if I require java 1.5, maven, subversion then I would have a batch file to load each into the environment, then have a master file that loads all of them for a standard environment.
This approach gives a lot of flexibility and is really easy to maintain and work with different environment simultaneously.
Most windows developers that develop on the microsoft stack of products probably use Visual Studio. For windows development without Visual Studio, SharpDevelop is the current most popular alternative.
However if you are looking for a user experience more similar to linux you can always use windows command prompt and all of the command prompt compilers still exist. Just like with linux you'll have to modify your environmental variables to make everything work you you'd like it to.
If that still isn't close enough to the feel on linux, you can try out Cygwin.
Many of your common utilities from linux like gdb do have windows builds as well.
And of course there is the Eclipse IDE that is used for many languages, by many people, on multiple platforms. It is very extendable.
Some other tools you may be missing:
GCC - Available Via Cygwin
MS Build can give you similar functionality to what you had with make (I'm not sure if nmake is still used/supported)
Vi/Vim
Grep
SysInternals will have lots of various file/process monitoring utilities to hopefully adequately replace what you miss being able to simply get from /proc
Wireshark(or ethereal) to replace well... wireshark/ethereal/
Tail is available in the Windows Resource Kit
Emacs
Hopefully that covers most of your basic tasks.
Microsoft now has a real shell for Windows: Windows PowerShell.
In addition to Cygwin, there are ports for a lot of the GNU utilities and toolchain to Windows. GnuWin32 seems to be a more up-to-date version than UnixUtils. MSYS is essentially a port of BASH to Windows, but it's fairly useless without the MinGW userland.
C++ / .NET Development: Visual Studio 2008
Java / PHP Development: Eclipse IDE, which also supports C/C++.
For a non-IDE solution, Notepad++ is a very good code highlighter that supports many languages.
Simply install cygwin. The quality has improved dramatically in recent years. I'm currently running cygwin x64 on Vista, and it's great.
One thing to especially take note of in cygwin is your path. Most troubleshooting with scripts and installed software should begin there.
The other tip I'd give is to use the rxvt terminal over the standard issue cygwin terminal. It might be installed by default nowadays, but check to make sure.
Visual Studio for .net/C++ (even the express editions are useful)
The sysinternals tools rock, especially Procmon and process explorer.
If you do native/C++ work knowing windbg can be helpful
Notepad++ and gvim are my preferred editors
For doing command line/shell stuff I often use python to write short scripts (for anything but the simplest batch file)
If you are familiar with .net then learning powershell isn't much of a stretch and there is a ton of functionality available

Developing in Ruby, on a Windows machine, is too counter productive?

It seems to be very counter productive in that so many gems will break on windows. I have been dealing with so many mysql and ruby-mysql gem problems (seg faults occuring in the gem itself, a class called UnixSocket apparently doesn't work well on windows machines, etc etc).
I'm I just wasting my time here? Should I move onto a different scripting language?
I have very little experience with Ruby on Windows but when I was starting with Ruby I was on Windows and I got the general impression that it wasn't a Windows-native system.
So after many years of using primarily Windows, getting into Ruby prompted me to switch back to my original system, Unix, this time to Linux. Ruby did run with less hassle and running bash in its native environment was better than the just-mostly-OK Cygwin. I was happy.
Then my new employer had me switch to the Mac. Now I'm really spoiled, but really happy.
I realize this is subjective but ISTM that Linux was a lot better than windows and the Mac is a lot better than Linux. I could still run Windows in VMWare Fusion if I wanted to, but I don't. I do have some Linux VM's.
I think what I'm really trying to say is that there is a reason Ruby isn't best deployed on Windows. The kind of people who run Ruby are .. I'm trying to think of a non-pejorative word here .. not likely to be found on Windows.
So this is a turning point for you. Yes, .net is a sophisticated and well-documented environment, yes, windows has been reliable for several years now, and yes, it's a respectable system at this point. Yes, it runs Stack Overflow and some of the gurus are Windows guys. But it's just kind of a litmus test for .. darn, missing that word again ..
A lot of people run Windows because they just don't know what else to run. Linux is a good alternative if you have to buy the system yourself. And if you or your employer can afford it, the (Unix-underneath) Mac gives you everything Linux does plus the Mac-specific world.
It's time to choose... :-)
I've been developing with Ruby on Windows for several years, including building and deploying "enterprise" intranet Rails apps running against Oracle, MySQL and SQLServer on both Windows and Solaris servers.
Agreed, there are a few gems that have compiled components whose authors have not built Windows versions - that's OK, it's an open-source platform and they don't have to if they don't want to. Similarly, you're perfectly entitled to (a) ignore libraries that don't have mswin32 or mingw32 versions or (b) give something back by compiling them yourself!
As for the MySQL gem, IIRC on Windows you need the "pure Ruby" adaptor, which does not use the MySQL C API: http://github.com/tmtm/ruby-mysql or gem install ruby-mysql
I don't think you're wasting your time. I've worked with two guys who've done extensive projects on Ruby on Rails apps using Windows XP, like major, long-term projects. They seem to not mind it at all. They both worked on it using the NetBeans IDE. (It has a Ruby-specific version.)
I tried it myself when I first got started with Ruby and didn't run into a lot of errors or problems with gems, though there were some things that worked awkwardly. Usually there was a workaround.
I decided that I greatly preferred using OS X or CentOS Linux for Ruby development. But I know for a fact that working on Windows is possible.
One thing to look out for is that 90% of the Ruby community is on OS X and deploys to Linux, so you'll get more help if you're on one of those OSs.
Another thing to look out for is that the whole Ruby universe and culture is very oriented towards the Unix command line using the bash shell. All your tutorials and stuff are going to kind of assume that. They're going to have instructions like "Go to the shell and run # rake db:migrate and it will be a lot easier to follow those instructions if you have a full-featured shell with command completion, command history, etc. So if you want to work on Windows you might look into installing something like MinGW.

Adding support of Windows to POSIX project... How painful? Is it worth the effort?

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

Patch stack tools for Windows

Are there any equivalents in the Windows world for patch stack management tools like Linux's quilt? I'm trying to come up with some development workflows for our environment, which need to work on both Linux and Windows. I can come up with a beautiful system for Linux using quilt and the like, but unless I can find a way to replicate it on Windows as well (including pretty GUI's for all the command-line-phobic developers), I'm basically stuck.
Maybe Mercurial's Queues can help? I do believe they work in the Windows implementation of Mercurial, too.
I use quilt on Windows by way of Cygwin.

Resources