-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coordinate porting to Windows #5430
Comments
@straight-shoota that's a good point. We need to figure out the basics of getting a blank |
Another area of priority is looking at c168035 and working out ways of reducing that stubbing. For example: get iconv working so we can remove the stubbing in |
A very basic working spec shouldn't be too hard I think. I've tried it earlier to figure out what might be needed for that. It seems to be missing mostly some basic file and dir methods. After disabling all feature options I even got a simple spec to compile, allthough it resulted a LLVM error at codegen. |
I'll take Fibers, I'll be able to start work on them after January 2nd. |
@straight-shoota looks like my |
Also of importance: deciding what to do about windows's UTF-16 use. There should definitely be a really quick and easy way of going between String -> UTF-16 This is an important issue: we shouldn't rely on iconv for this (I presume it's slow for small strings, and we don't have it in windows anyway). We need to write UTF-16 infrastructure for all platforms first. |
Here's my branch porting I'll turn "Remove c/winbase" and "Add Crystal::System::Dir" into PRs. |
Another idea before I forget it: Consolidate all stubbing out into one huge |
You mean to remove winapi.cr, not winbase. |
@straight-shoota yep, thanks, commit message is wrong. Shouldn't be working at 1am... |
Made those PRs: #5447 and #5448. I hope you don't mind me editing the checklist in your issue @straight-shoota. |
Looks great! I've deliberatly added a note at the end of the OP for that purpose ;) |
Great news! Thank you for this. |
In https://github.com/crystal-lang/crystal/wiki/Porting-to-Windows, should:
... be:
|
@drhuffman12 thanks, fixed! |
@straight-shoota , yw |
Due to time constraints and last minute events I won't be able to work on Fibers as expected :(. If someone else wants to claim them, that would be amazing. |
If you can get openssh server working on WSL (hint: you need to edit #!/bin/sh
set -euo pipefail
windows=192.168.xxx.xxx
bin/crystal build --progress --cross-compile --target x86_64-unknown-windows-msvc -o .build/cross "${@}"
scp -P 2222 .build/cross.o $windows:/mnt/c/crystal/cross.o
cat <<EOF | ssh -p 2222 $windows bash
export PATH="$PATH:/mnt/c/Windows/System32"
cmd.exe /S /c "C:\Program^ Files^ ^(x86^)\Microsoft^ Visual^ Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat x64 && cd \crystal && cl cross.o /Fecross pcre.lib gc.lib libcmt.lib"
cd /mnt/c/crystal
echo
./cross.exe
EOF
This script assumes you have |
A script to automatically generate a compilable manifest of the entire spec suite, with broken tests commented out with a vague reason: cd spec
for spec in ./std/**/*_spec.cr; do
(cd .. && crystal-windows spec/$spec) >/dev/null 2>/dev/null && echo "require \"$spec\"" ||
(../bin/crystal build --no-codegen --target x86_64--windows-msvc $spec >/dev/null 2>/dev/null && echo "# require \"$spec\" (failed to run)" || echo "# require \"$spec\" (failed to compile)")
done
|
The script posted by @RX14 is intended to be run on an external system which connects to WSL through SSH to upload the object file and run the linker through Windows interoperability feature. |
As I see, there is no dir.cr in crystal/system/win32, so I'm going to make it. |
@txe Fantastic to see you back! I'm working on I have a lot of work not in Namely, working in my branch but not |
Some personal comments:
So overall, I think there's not much standing in the way of proclaiming Windows as a supported platform. My must-have list for that is rather short (maybe I'm missing something, though).
|
Just my 2 cents, but it's useful to, say, work with (virtual) COM Port. |
I was actually surprised Is there any reason not to implement |
Right, pipes in Go are implemented in pure Go, no file descriptors at all. We wanted to do that eventually with Juan but we never got to it. |
Yeah, when I realized, I assumed you used POSIX FDs simply because that was quicker at the time and didn’t intend that to be part of the semantics of the pipe. Is there an open issue for this? I have some terrible code written for it that mostly works. |
The most relevant discussion seems to be in #8152. But if we are passing pipes across processes, possibly ones that aren't written in Crystal, wouldn't that require an OS-backed pipe anyway? |
Let's continue the discussion about re-implementing pipes in Crystal in #12238 |
@89z I think he means from a stdlib usability point of view. I.e. you can actually use Crystal on windows fairly stably, even if it requires Visual Studio. Having something working and usable is more important to the end user compared to which backend is used when the latter is something that can be added in after the former is working. See #5430 (comment). |
Does it require Visual Studio? I though we were binding to standard Windows functions |
A little further down in the file it is ignoring what crystal/src/compiler/crystal/compiler.cr Line 360 in b56e786
It probably should be updated to:
|
I just ran into the issue where Windows can't find |
The scoop package has the same issue for the moment, still trying to coordinate a fix. |
@neatorobito Ah, you're right. Same issue. |
@mdwagner I've tested and pushed a fix for this in the scoop repo, please give it a try when you get a chance. |
@neatorobito I updated to the new version in Scoop, but still have the same issue. |
@mdwagner Can you please open a dedicated issue for this? It's out of scope for this meta issue. Please add details on your system setup (like install location of VS Build Tools). |
Isn't it high time this + #26 + #7339 be closed ? (since as per this comment, #7339 is completed as #12224 + #12284 being completed) and move focus to other issues? |
No, it's not. That would then mean the bulk of the Windows port is completed as per the TODO list in this issue. But there are still a lot of very rough edges, so #26 is still a way to go. |
Hi, from the TODO list, it's seem like Signal should works on windows, but it build failed on my github action platform is ms-windows 2022.
Please have a look, following is log. https://github.com/crystal-china/translater/actions/runs/4906504148/jobs/8761004602 |
They should use |
9 Years passed and still no Windows support. This is why Crystal will unfortunately always be a niche language for a small minority. |
All I have seen here for the last 4 years is, New "Windows Related" Issues are piling up everyday. Instead of resolving the old ones. 😂 |
Not surprised, checked the funding and it just was not there. I've moved on to other languuages with better marketing. The ecosystem is moving on, without Crystal. |
I mean have any of you actually tried it? Windows support is, and has been for a while, at the point where you can pretty much install via the provided installer on the GH release and use it as you would on any other OS. There are still some loose ends that need to be figured out, but I don't think it's fair to say "there is no windows support." |
You can compile on windows, you can create windows gui applications, you can create directx applications. What do you think is still missing? |
UPDATE 2023-04-24:
All the main platform features for Windows are finished! 🚀
There are still some smaller stories pending. Project board: https://github.com/orgs/crystal-lang/projects/11/views/5
You can support the ongoing development financially: Windows suppport project on Open Collective.
UPDATE 2021-11-18:
By now, the compiler works pretty well on windows and most of the standard library has been ported as well. Besides a couple other smaller missing pieces, the major gap is in concurrency-related features held back by the missing event loop implementation.
With #5339 being merged, the first step of bringing Crystal to Windows has been accomplished!
With current master branch it is possible to cross-compile and run simple programs (alá Hello, World!) on native Windows.
Obviously we're still far away from porting the compiler or entire standard library to windows. This issue is supposed to coordinate and keep track of ongoing efforts to add support for more and more of the crystal standard library.
TODO
The primary focus should be on the core library (somewhat odered by priority):
Mutex
on Windows #12213Socket
to win32 #10696And of course a CI infrastructure once specs are running on windows.
Proceedings
The general course of action is to extract platform-specific implementations and then add the implementation for win32 platform.
A lot of work has already been done in #3582 but it needs to be updated and chopped into smaller pieces of changes.
The first goal should probably be to get specs running on windows to be able to verify the windows implementations. Essential for this are as far as I can see file, dir, exceptions (backtrace!), process and signal.
If you want to help with that effort, or want to "take" a piece of that work to work on, please comment below.
Useful References
Please feel free to add and edit this post as appropriate (core team).
The text was updated successfully, but these errors were encountered: