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.
Related
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.
Starting with the next version of Mac OS X, Java will no longer be included in the system and I don't want to force my customers to install it themselves. So I would like to do what I do on Windows - bundle it with my app. It also gives me some hope that it could get included in the Mac App Store.
Where can I download a Mac OS X JRE that I could include with my application? Or can I just copy the one that's installed on my Mac?
Update (4/15/2013):
As Thorbjørn helpfully pointed out, Oracle now has a solution for this. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html. However, I'm keeping the original content for "historical purposes", and because it was a fun research project.
Previous version (with edits):
This is a great question. I was going to respond that you are simply ahead of your time -- as you pointed out, Java is not going to be removed until the Lion release. However, this article makes it clear that using Java today is not allowed:
Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.
At the same time, no one has announced a redistributable JRE for Mac OS X yet. I think your best bet, bearing in mind that you are forging new ground, is to check out the Mac OS X Port wiki page of the OpenJDK project. It does describe how to compile your own JDK, but it does not clearly state whether or not the resulting JDK can be "bundled" cleanly or not. I think you will have to try it and see :-(.
Also, it's not clear if the OpenJDK licensing allows this at all (IANAL). Hopefully someone else has already figured this out with regard to Linux/Windows, although of course the rules may be different for the Apple contributions.
Hope this helps. If nothing else, it's a starting point.
EDIT: I am going to throw out one additional suggestion. We now know that Mono apps can be packaged for the App Store. Furthermore, IKVM.NET is a complete implementation of Java that runs on top of Mono. You could try, in theory, to put these two pieces together and get a Java app, bundled for the App Store, that does not in fact require a JRE!
If you try this, I would love to hear how it works out :-).
EDIT 2: Unfortunately, the App Store and the GPL do not appear to be compatible (see http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046). The OpenJDK license isn't exactly the same as the GPL, but it's pretty close (again, IANAL). Therefore, Mono & IKVM.NET may be your best bet. Good luck!
In the same web search that I found this question, I've found the these instructions from the OpenJDK project. Not having tried them myself, I cannot comment on how well they work.
Meanwhile, another, very detailled article was published by Marco Dinacci which also goes into signing and sandboxing.
Apple has joined the Sun/Oracle OpenJDK open source project last month, so Java on Apple is alive and kicking.
Just tell the user to download and install the OpenJDK JRE for Mac OSX (when it becomes available, right now it´s just source code).
And no. you cannot include "the folder that is in your mac" without permission as it is copyrighted code from Apple.
Finally, packaging a "private JRE" is a very bad practice, it will make your app bloated, andif the user ends up running several Java apps, he will end up running multiple Java VMs simultaneously which is a terrible waste of system resources.
I'm now learning Ruby because I saw it's a very powerfull language, but now I want to know what mobile ports of Ruby we have and for what devices.
PS: I have a HTC S711, HP iPAQ Hx2, Nokia E61, Nokia N95, Palm T|X, Palm Z22, HP Jornada 720..., it's better if I can use it on these platforms, but I'm open to buy other devices, as I'm a mobile addict.
There's a couple of possibilities:
JRuby can run pretty much anywhere where there is a JVM, which means pretty much anywhere except iPhone. (Apparently, there's even JVM implementations for Windows Mobile.) Note that you need a special stripped-down version for JME-CDC (Java Platform Micro Edition - Connected Device Configuration), which hasn't been updated in a while. However, if you ask nicely, someone will probably at least help you build your own (it basically involves deleting stuff from the main version, recompile, test, delete more, recompile, test, ...).
JRuby can also run on Android. In fact, there's three versions available: JRuby is part of the Android Scripting Environment (ASE), and then there's JRuby lead developer Charles Oliver "Headius" Nutter's Ruboto. The very latest addition is JRuby for Android by Pascal Chatterjee.
MRI was once ported both to Symbian S60 (Nokia) and Windows CE, although I have no idea how hard that is to get working, how current these ports are, whether they are integrated into the official sourcetree or are maintained seperately (if at all) nor if it also applies to YARV. There is a Symbian subdirectory in the YARV sourcecode which was last updated just 5 days ago, and a Windows CE subdirectory in the MRI sourcecode which was updated 6 months ago, though.
Apparently, MRI also runs on the iPhone.
YARV was recently ported to Android.
It looks pretty likely that MacRuby will, in the future, run on the iPhone. The MacRuby developers all either work for Apple or have signed NDAs and are therefore not allowed to say anything, but when one of the lead developers was asked what the new Ahead-of-Time compiler in MacRuby 0.5 would be useful for, he oracled something like "running Ruby on resource-constrained ARM-powered pocket-sized mobile internet devices with security restrictions regarding interpreted code" or something similarly cryptic.
The same applies to IronRuby: since IronRuby runs on Silverlight and Silverlight is Microsoft's new phone platform (or everything-platform, really), I wouldn't be surprised to see IronRuby on at least the new Windows Phone 7. [EDIT: Actually, it already does, IronRuby on Windows Mobile 7 was demonstrated at MIX10.]
In the meantime, the Rhodes mobile framework by Rhomobile allows you to develop cross-platform (iPhone, Windows Mobile, RIM (Blackberry), Symbian (Nokia) and Android) native mobile applications using HTML as the UI. The way it basically works, is that you write your UI in HTML which gets displayed by the native browser control that is built into the phone, and the Rhodes framework then supplies the necessary CSS and JavaScript to make it look and feel "native". However, it's not a web application: the webserver that serves the HTML also runs on the phone, as does the Ruby interpreter in which you run your models and controllers. (See this answer I gave to another question for more details.) Even if you don't want to use their framework, you can still steal their different Ruby interpreters for the different platforms. E.g., they actually use XRuby, not JRuby for their Blackberry port and YARV via the Android Native Development Kit for their Android port.
I have tried Ruby on Symbian about a year back, it was easy to get going but was a bit limited in how it integrated into the phone. I see the project have progressed a lot since then. I will definitely try it out again.
Coming soon: MobiRuby is an upcoming (Summer 2012) project using the mruby interpreter. It's iOS specific, but I wouldn't be surprised to see mruby use elsewhere in the coming months.
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.
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