So at FactorCon 2007, Doug and I experimented with getting Factor going on 64-bit Windows XP. The Factor compiler and FFI is ready to go, and it should be an easy port in theory, but the only problem is that we have to compile the VM (which is written in C). And this isn't trivial at all. Here is what we found:
- First of all, Factor compiled with 32-bit Cygwin runs in 32-bit mode under "WoW emulation", however certain features don't work, for example UDP support. This is a bug in Windows and there's nothing we can do; a C testcase demonstrates the problem quite clearly. The problem is not present in 64-bit mode.
- Cygwin also ships with broken implementations of certain C runtime functions, such as
_osf_openhandle(). We have a testcase which fails in Cygwin and works in Visual Studio (I reported the bug to the Cygwin guys.) - 32-bit Mingw is highly unstable on 64-bit Windows -- you need an obscure workaround just to get it to run at all -- however it does not suffer from the
_osf_openhandle()bug. The UDP sockets problem is still there since its a Windows bug, not specific to Cygwin or Factor. - There's a 64-bit Mingw port in progress, however we were unable to get it to work. Using optimization flags crashes gcc; without optimization flags gcc produces a non-functioning binary, and PE Explorer claims this binary is corrupt.
- There are no plans at all to port Cygwin to 64-bit Windows.
So the executive summary is that we're pretty much fucked when it comes to 64-bit Windows support, and all because I made a serious miscalculation and used GNU C extensions in the VM. I should have stuck with semi-portable C and then we could use Visual Studio...
If we could compile the Factor VM as a 64-bit binary, then porting the rest of Factor would be trivial; after all, we support Windows, and we support AMD64, and we're awesome programmers. However, the GNU hippies fucked up once again and failed to deliver -- AMD64 chips have been out since 2004 and Windows XP x64 edition was released at the start of 2005, but at the end of 2007, more than two years later, there is still no stable 64-bit GNU toolchain available for Windows.
I realize that this is all just people's hobbies, they work on Cygwin/Mingw in their spare time, I shouldn't expect timely releases or stability of any sort, etc. But hell, if you GNU people want "world domination", if you want us to stop using Mac OS X, Windows and other commercial software, if you want market share greater than 0.00001%, if you want people to take GNU and Linux seriously, get to work and fix your shit. Thank you.
9 comments:
Slava-
On behalf of the Cygwin folk (I am not one), let me say "Fuck You".
There, now that that's out of the way, I'll elaborate. Cygwin has made my life on Windows platforms sooo much more pleasant than it would otherwise have been, I have nothing but gratitude for them.
Concern about the availability of cygwin is one reason I went and bought my latest Win machine before Vista came out. And I guess I'm not going to go 64 bit any time soon either.
You made the decision to go with windows, and we all know that windows charges ahead before they really should. Heck, they've been selling an OS without a decent shell or set of GNU utilities for years. If you really want cygwin to go 64bit, you've got three choices that I can see - 1) Do it yourself (okay, I know that's impractical), 2) Pay someone to do it, or 3) Contact your vendor (msoft), and ask what they will do the help bring it about.
[Wasn't msoft providing a set of Unix tool a while ago (2-3 years)? Maybe they're providing them for 64bit as well?]
I'm sorry to be so nasty, but I don't like seeing the cygwin folk treated so rudely. They've done too much for me in the past.
Or you could get your fat ass from the couch and scratch your needs with your own hand - and get involved in those GNU world domination plans :)
But isn't "not creating a usable compiler for 64-bit windows" actually helping their goal of "wanting you to stop using Mac OS X, Windows and other commercial software"?
to the first anonymous: "fuck you" is not an appropriate thing to say to your users. I'm glad you're not a cygwin developer, because if a cygwin developer told his users "fuck you" then many people would re-evaluate whether they want to use cygwin or not. I don't care about the GNU command line or anything like that. I spend most of my screen time switching between jEdit and Factor. jEdit already has a Console plugin which provides a very powerful command line. I do care about the GNU compiler toolchain, though.
to the last anonymous: the lack of a GNU toolchain for 64-bit Windows won't influence me one way or another to use or not to use Linux. I use Linux for server tasks and don't see myself switching to anything else there.
Also, FWIW, cygwin works on vista.
Slava I agree with you from a technical, and consumer perspective. I purchased a 64bit PC with 4GB ram, a 4850 video card, and a 64bit OS thinking that the world had to be ready in 2008. Unfortunately 64bit users don't have native Flash in Linux 64, and Win 64 users don't have native Cygwin. Sure there are workarounds in both cases, but if I could pay for a native 64bit version of either product I would. Yeah, sorry some of us can't code. Its sad that games developers are taking 64bit more seriously than other developers. I certainly lack the skill to develop it. Thanks for writing this article and shedding light on this annoyance.
BA
Cleveland, Ohio
The way it works is this: you notice gcc, etc.. don't work nice on 64bit Windows, you are a kick ass programmer and you need it to work, so you fix it and send them patches, they integrate it... then I enjoy ;-)
And you get to learn something about compiler guts on the way. This is the development model. Though the easier path is probably to take out the GNU extensions and build with VC.
Agree on the Cygwin/x64-vista thing, quite annoying.
There are lots of other Cygwin bugs - as soon as you start running multiple Cygwin processes in parallel, it completely breaks down, for example. Especially bigger apps such as Bash will fail completely within a very short time. That's also been the situation for years.
The most problematic issue surrounding Cygwin, in my opinion, is that there's no bug tracker for the product, so the issues linger on for years. The main developers are handling bug reports on the mailing list, but in an extremely arrogant and derisive way, effectively scaring off anyone who wants to help find bugs. Ultimately this results in loads of stuff going unfixed for years. Only if you're willing to wade through a gazillion emails worth of mailing list postings are you going to know that the product is ripe with unfixed issues.
Anyway, a solution that I did not like much to begin with (not open source), but which has turned out to work just GREAT for us is to use MKS Toolkit. It's payware, but it's infinitely better than Cygwin. It has a single outstanding bug which annoys me like hell, and product support is just about as bad as for Cygwin, but at least the thing works 99.9% of the time. Well worth a try!
It comes with a GNU toolchain, too, AFAIK.
Best of luck with the project.
To the above poster: I'm not sure what your problem is with bash and multiple processes in Cygwin, but I've had a bash instance running in an XTerm on my Windows desktop for years (for months at a time without a restart) and it's still doing just fine.
I do a lot of serious work in Cygwin, including building and maintaining a large software system made up of hundreds of small utilities, whose primary target platform is Linux. Everything works great on Cygwin for me, always has. People over here can't stop raving about it.
That said, I couldn't agree more about the lack of bug-tracking and general grumpiness. That is a peeve. Meh, you get what you pay for.
It would be fun to start a 64-bit project (maybe a fork?) but we'd a need a fair number of enthusiastic, knowledgeable people to get started.
Post a Comment