Crystal: Support Windows as a first class platform (note: not WSL or emulation)

[xtagon]

Hi,

Crystal is an exciting project with lots of potential. I am interested in the possibility of a Crystal compiler for Windows. How feasible is that idea, and how much work would it be?

Specifically, I would like to be able to compile a Crystal program into a Windows .DLL file with exported C functions. I don't care if I run the actual Crystal compiler on a Linux or Windows machine, I just want to end up with a DLL library that will run on Windows.

I have knowledge of Ruby and some C, and I'm willing to dive into learning about LLVM if it means I can contribute here. I would be pleased if you could point me in the right direction.

Regards,
Justin

[asterite]

Hi,

Thank you for your interest in Crystal!

Yes, it would be awesome to have Crystal running on Windows.

I don't think there is much to do on LLVM side to make it work, except having the necessary libraries to link to.

I read this the other day, it might be useful: http://www.phoronix.com/scan.php?page=news_item&px=MTQ1NjI

If you want to contribute, I think the path is the following:

• Checkout the project and try to compile a simple program. A very simple program is just this: "1" (just an integer literal). But Crystal automatically includes a "prelude" file that gives you Array, Hash, etc. So you should comment these two lines (https://github.com/manastech/crystal/blob/master/lib/crystal/compiler.rb#L120-L121) so it will be easier to test. This point involves making LLVM work on Windows, specifically the ruby-llvm gem.
• Once the previous point is working, you will need to make other programs work, mostly programs that depend on libc. For example you could try opening and writing a file with File.open("C:/foo.txt") { |file| file.write "Hello" }. If the API for opening and writing a file is different on Windows than on unix (and I'm sure it is), you will have to create separate files for Windows. For this there is a temporary solution: you can place an "if" after a require. Take a look at the first two lines of https://github.com/manastech/crystal/blob/master/std/time.cr

Any doubts you have about how the compiler works, we can answer and help you :-)

Regards,
Ary

[xtagon]

Thanks, Ary! I will give it a shot.
On Sep 10, 2013 5:09 AM, "Ary Borenszweig" [email protected] wrote:

Hi,

Thank you for your interest in Crystal!

Yes, it would be awesome to have Crystal running on Windows.

I don't think there is much to do on LLVM side to make it work, except
having the necessary libraries to link to.

I read this the other day, it might be useful:
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1NjI

If you want to contribute, I think the path is the following:

• Checkout the project and try to compile a simple program. A very
  simple program is just this: "1" (just an integer literal). But Crystal
  automatically includes a "prelude" file that gives you Array, Hash, etc. So
  you should comment these two lines (
  https://github.com/manastech/crystal/blob/master/lib/crystal/compiler.rb#L120-L121)
  so it will be easier to test. This point involves making LLVM work on
  Windows, specifically the ruby-llvm gem.
• Once the previous point is working, you will need to make other
  programs work, mostly programs that depend on libc. For example you could
  try opening and writing a file with File.open("C:/foo.txt") { |file|
  file.write "Hello" }. If the API for opening and writing a file is
  different on Windows than on unix (and I'm sure it is), you will have to
  create separate files for Windows. For this there is a temporary solution:
  you can place an "if" after a require. Take a look at the first two lines
  of https://github.com/manastech/crystal/blob/master/std/time.cr

Any doubts you have about how the compiler works, we can answer and help
you :-)

Regards,
Ary

—
Reply to this email directly or view it on GitHubhttps://github.com/manastech/crystal/issues/26#issuecomment-24154638
.

[asterite]

I forgot to mention there are thousands of specs, so if you manage to pass
them all you will be very close.

Lexer, parser, normalization and type inference specs, except those
involving macros, should pass right away. Codegen specs will be the tough
ones.
On Sep 10, 2013 9:29 AM, "Justin Workman" [email protected] wrote:

Thanks, Ary! I will give it a shot.
On Sep 10, 2013 5:09 AM, "Ary Borenszweig" [email protected]
wrote:

Hi,

Thank you for your interest in Crystal!

Yes, it would be awesome to have Crystal running on Windows.

I don't think there is much to do on LLVM side to make it work, except
having the necessary libraries to link to.

I read this the other day, it might be useful:
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1NjI

If you want to contribute, I think the path is the following:

• Checkout the project and try to compile a simple program. A very
  simple program is just this: "1" (just an integer literal). But Crystal
  automatically includes a "prelude" file that gives you Array, Hash, etc.
  So
  you should comment these two lines (

https://github.com/manastech/crystal/blob/master/lib/crystal/compiler.rb#L120-L121)

so it will be easier to test. This point involves making LLVM work on
Windows, specifically the ruby-llvm gem.

• Once the previous point is working, you will need to make other
  programs work, mostly programs that depend on libc. For example you
  could
  try opening and writing a file with File.open("C:/foo.txt") { |file|
  file.write "Hello" }. If the API for opening and writing a file is
  different on Windows than on unix (and I'm sure it is), you will have to
  create separate files for Windows. For this there is a temporary
  solution:
  you can place an "if" after a require. Take a look at the first two
  lines
  of https://github.com/manastech/crystal/blob/master/std/time.cr

Any doubts you have about how the compiler works, we can answer and help
you :-)

Regards,
Ary

—
Reply to this email directly or view it on GitHub<
https://github.com/manastech/crystal/issues/26#issuecomment-24154638>
.

—
Reply to this email directly or view it on GitHubhttps://github.com/manastech/crystal/issues/26#issuecomment-24155615
.

[xtagon]

I apologize for forgetting to follow up on this. I was able to compile LLVM on Windows (that was a "fun" task in itself) but failed to get ruby-llvm working with it and eventually gave up (for now).

The website says that the Crystal compiler is now written in Crystal itself. Does that carry any implications as to how one might get it running on Windows? Do you think a better pursuit would be to make Crystal cross-compile (compile on Linux, run on Windows)?

[asterite]

Well, if you get cross-compilation to work that would indeed be awesome and very, very useful.

If you are on Mac or Linux you can download a preocmpiled compiler that will let you compile new versions of the compiler. Since such compiler doesn't exist for Windows, you will need to create one, but I'm not sure how. There are the options:

1. Checkout the tag "ruby" and make that compiler work (in Ruby). That would involve making 'ruby-llvm' work, I guess. It will also involve making the code written in Crystal to work in windows (currently the compiler relies on some commands like "uname" to determine the operating system, I'm not sure cygwin or the libc for windows that we'll use will have those).
2. Make cross compilation work. This has the advantage of not having to deal with 'ruby-llvm' (the LLVM wrapper in Crystal is much thinner and it's easier to make it work). I would try first to cross compiler from linux to Mac or from Mac to linux (if you have those available) to understand what is needed for cross compiling, and then try to cross compile to Windows.

Maybe you can tell us what problem you had with ruby-llvm on Windows. If you make that work, point 1 would be the easiest, I think.

Thanks!

[xtagon]

ruby-llvm says it requires LLVM built with shared library enabled. However, the LLVM CMake doc says "Shared libraries are not supported on Windows and not recommended in the other OSes."

I don't know whether "not supported" means it's not possible, so I'll try rebuilding LLVM and find out.

[xtagon]

Here is what happens when I try to install ruby-llvm:

C:\Users\Justin>gem install ruby-llvm --no-rdoc --no-ri --platform=ruby
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
ERROR:  Error installing ruby-llvm:
        ERROR: Failed to build gem native extension.

    "C:/Ruby200-x64/bin/ruby.exe" -rubygems C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/rake-0.9.6/bin/rake RUBYARCHDIR=C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/ruby
-llvm-3.0.0/lib RUBYLIBDIR=C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/ruby-llvm-3.0.0/lib
g++ -shared support.cpp -IC:/Users/Justin/beta/sandbox/crystal/llvm/include -IC:/Users/Justin/beta/sandbox/crystal/build/include  /DWIN32 /D_WINDOWS /W3 /GR /EH
sc   /MP -wd4275 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_S
ECURE_NO_WARNINGS -wd4146 -wd4180 -wd4244 -wd4267 -wd4345 -wd4351 -wd4355 -wd4503 -wd4624 -wd4800 -wd4291 -w14062 -we4238 -D__STDC_CONSTANT_MACROS -D__STDC_FORM
AT_MACROS -D__STDC_LIMIT_MACROS -LC:/Users/Justin/beta/sandbox/crystal/build/lib/  /machine:X86   -lLLVMJIT -lLLVMOption -lLLVMIRReader -lLLVMAsmParser -lLLVMIn
terpreter -lLLVMInstrumentation -lLLVMDebugInfo -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTableGen -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLL
VMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMBitReader -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMX86
Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -
lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMR600CodeGen -lLLVMR60
0Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMNVPTXCod
eGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMMipsDisassembler -
lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHex
agonInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter
-lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMi
pa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMAArch64AsmParser -lLLVMMCParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -
lLLVMMCDisassembler -lLLVMMC -lLLVMObject -lgtest_main -lgtest -lLLVMSupport  -o ../../lib/RubyLLVMSupport-3.0.0.dll
g++: error: /DWIN32: No such file or directory
g++: error: /D_WINDOWS: No such file or directory
g++: error: /W3: No such file or directory
g++: error: /GR: No such file or directory
g++: error: /EHsc: No such file or directory
g++: error: /MP: No such file or directory
g++: error: unrecognized command line option '-wd4275'
g++: error: unrecognized command line option '-wd4146'
g++: error: unrecognized command line option '-wd4180'
g++: error: unrecognized command line option '-wd4244'
g++: error: unrecognized command line option '-wd4267'
g++: error: unrecognized command line option '-wd4345'
g++: error: unrecognized command line option '-wd4351'
g++: error: unrecognized command line option '-wd4355'
g++: error: unrecognized command line option '-wd4503'
g++: error: unrecognized command line option '-wd4624'
g++: error: unrecognized command line option '-wd4800'
g++: error: unrecognized command line option '-wd4291'
g++: error: unrecognized command line option '-w14062'
g++: error: unrecognized command line option '-we4238'
g++: error: /machine:X86: No such file or directory
rake aborted!
Command failed with status (1): [g++ -shared support.cpp -IC:/Users/Justin/...]

Tasks: TOP => default => build => RubyLLVMSupport-3.0.0.dll
(See full trace by running task with --trace)


Gem files will remain installed in C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/ruby-llvm-3.0.0 for inspection.
Results logged to C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/ruby-llvm-3.0.0/ext/ruby-llvm-support/gem_make.out

Any ideas?

Windows 7 64-bit
Ruby 2.0.0p353 (with DevKit)
Rubygems 2.0.14

[Kelet]

Hello,

I've been watching the development of Crystal for a while now, and I've become interested in possibly contributing to the ecosystem.

I'm posting in this issue because Windows support is integral to my adoption of the language. I work on both Windows and Linux and need all of my tools to work on both.

I'll be busy for the next couple of weeks, but I should have some free time toward the end of the month. I'd like to try and get Crystal compiling on Windows if possible. Is this information up to date? Judging by some of the recent blog posts, it seems out of date.

[asterite]

Hi @Kelet,

First, thanks for wanting to help in the development of Crystal!

My last comment is still up-to-date, I think. But now I think the best thing to do is to cross-compile from mac/linux to Windows. We can start by making a very simple "Hello World" and try to run it on Windows. This will be the program:

# file: hello.cr
lib C
  fun puts(str : UInt8*) : Int32
end

class String
  def cstr
    pointerof(@c)
  end
end

C.puts "Hello World!"

We will compile it like this:

bin/crystal foo.cr --prelude=empty --single-module

The "--prelude=empty" tells the compiler to not include the file prelude.cr and instead use empty.cr. This just defines the main function, which will contain whatever is in your program.

The "--single-module" just makes it generate a single LLVM module, otherwise it generates one per class/module. So this way is simpler.

Then we bind to the C function puts, which I don't know if it exists in Windows. If not, it should be replaced by another one provided by Windows that does that (I don't know much about Windows, it seems it does exist)

Then the String#cstr method just gets a pointer to the first character in the String. This method is used to implicitly convert a String to UInt8* by the compiler (I guess that method should be built-in so we don't have to do this...). But it's not a big deal anyway.

Then if you run it like this:

DUMP=1 bin/crystal foo.cr --prelude=empty --single-module

you will see the generated LLVM code:

; ModuleID = 'main_module'

%String = type { i32, i32, i8 }

@symbol_table = global [0 x %String*] zeroinitializer
@str = private constant { i32, i32, [13 x i8] } { i32 1, i32 12, [13 x i8] c"Hello World!\00" }

define i32 @__crystal_main(i32 %argc, i8** %argv) {
alloca:
  br label %const

const:                                            ; preds = %alloca
  br label %entry

entry:                                            ; preds = %const
  %0 = call i8* @"*String#cstr<String>:UInt8*"(%String* bitcast ({ i32, i32, [13 x i8] }* @str to %String*))
  %1 = call i32 @puts(i8* %0)
  ret i32 %1
}

define i32 @main(i32 %argc, i8** %argv) {
alloca:
  %argc1 = alloca i32
  %argv2 = alloca i8**
  br label %entry

entry:                                            ; preds = %alloca
  store i32 %argc, i32* %argc1
  store i8** %argv, i8*** %argv2
  %0 = load i32* %argc1
  %1 = load i8*** %argv2
  %2 = call i32 @__crystal_main(i32 %0, i8** %1)
  ret i32 0
}

define internal i8* @"*String#cstr<String>:UInt8*"(%String* %self) {
alloca:
  br label %entry

entry:                                            ; preds = %alloca
  %0 = getelementptr %String* %self, i32 0, i32 2
  ret i8* %0
}

declare i32 @puts(i8*)

We can get that LLVM code, put it in a file "hello.ll" in Windows and try to compile it:

llc hello.ll
clang hello.s -o hello
./hello
# prints: Hello World!

Of course these last commands are in linux/mac, for Windows it will be similar. We are using LLVM 3.3 so the commands might be named like llc-3.3, clang-3.3 and so on.

I don't know if in Windows the main function is just "int main(int argc, char** argv)" or you always need to use WinMain (I think that's for graphical stuff).

There's a simple way to do all of the above: we use the --cross-compile flag:

bin/crystal hello.cr --prelude=empty --single-module --cross-compile "windows"

This will genreate a hello.bc file (similar to ll file, but binary). The last command will also print this:

llc hello.bc  -o hello.s && clang hello.s -o hello

So you copy the "hello.bc" file to Windows and executing that command should generate an executable.

The "windows" part passed to the --cross-compile flag just passes "windows" as a flag to the compiler so when you use ifdef it will be true. In linux/mac these flags are obtained by executing uname -m -s, lowercased and split by spaces. In fact, right now you can pass "" to the --cross-compile flag, but once we start with more complex program it would be nice to separte all windows stuff with ifdef windows.

If you manage to compile a Crystal program in linux/mac, copy the ll/bc file to Windows, compile it in Windows, execute it and get "Hello World!" in the conosle, we'll be a bit closer to having a compiler in Windows :-)

The next steps would be trying to compile bigger programs until we reach the program that is the compiler itself :-P

If you make some progress with the above, please let us know and we can continue trying to make it work.

Again, thanks for your help!

[Kelet]

Excellent, I'll try this process when I find some time and report back to you!

[Kelet]

I tried it out real quick:

$ llc hello.bc -o hello.s && clang -v hello.s -o hello
clang version 3.4 (198054)
Target: i686-pc-mingw32
Thread model: posix
Selected GCC installation:
 "c:\TDM-GCC-32\bin\gcc.exe" -v -c -m32 -o "C:\\Users\\Kyle\\AppData\\Local\\Temp\\hello-d405d2.o" -x assembler hello.s
Using built-in specs.
COLLECT_GCC=c:\TDM-GCC-32\bin\gcc.exe
Target: mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=mingw32 --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections -DWINPTHREAD_STATIC' --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --with-pkgversion=tdm-2 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.8.1 (tdm-2)
COLLECT_GCC_OPTIONS='-v' '-c' '-m32' '-o' 'C:\Users\Kyle\AppData\Local\Temp\hello-d405d2.o' '-mtune=generic' '-march=pentiumpro'
 c:/tdm-gcc-32/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o C:\Users\Kyle\AppData\Local\Temp\hello-d405d2.o hello.s
GNU assembler version 2.23.1 (mingw32) using BFD version (GNU Binutils) 2.23.1
hello.s: Assembler messages:
hello.s:18: Error: invalid character '"' before operand 1
hello.s:45: Error: junk at end of line, first unrecognized character is `"'
hello.s:50: Error: junk at end of line, first unrecognized character is `"'
clang.exe: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)

hello.s

    .def     @feat.00;
    .scl    3;
    .type   0;
    .endef
    .globl  @feat.00
@feat.00 = 1
    .def     ___crystal_main;
    .scl    2;
    .type   32;
    .endef
    .text
    .globl  ___crystal_main
    .align  16, 0x90
___crystal_main:                        # @__crystal_main
# BB#0:                                 # %entry
    pushl   %eax
    movl    $L_str, (%esp)
    calll   "_*String#cstr<String>:UInt8*"
    movl    %eax, (%esp)
    calll   _puts
    popl    %edx
    ret

    .def     _main;
    .scl    2;
    .type   32;
    .endef
    .globl  _main
    .align  16, 0x90
_main:                                  # @main
# BB#0:                                 # %alloca
    subl    $16, %esp
    movl    24(%esp), %eax
    movl    20(%esp), %ecx
    movl    %ecx, 12(%esp)
    movl    %eax, 8(%esp)
    movl    12(%esp), %ecx
    movl    %eax, 4(%esp)
    movl    %ecx, (%esp)
    calll   ___crystal_main
    xorl    %eax, %eax
    addl    $16, %esp
    ret

    .def     "_*String#cstr<String>:UInt8*";
    .scl    3;
    .type   32;
    .endef
    .align  16, 0x90
"_*String#cstr<String>:UInt8*":         # @"*String#cstr<String>:UInt8*"
# BB#0:                                 # %alloca
    movl    4(%esp), %eax
    addl    $8, %eax
    ret

    .bss
    .globl  _symbol_table           # @symbol_table
    .align  4
_symbol_table:

    .section    .rdata,"r"
    .align  16                      # @str
L_str:
    .long   1                       # 0x1
    .long   12                      # 0xc
    .asciz  "Hello World!"
    .zero   3

[asterite]

Cool! That's progress.

It seems clang for windows doesn't like names like "__String#cstr:UInt8_" for labels.

What happens if you change:

"_*String#cstr<String>:UInt8*"

to this:

in the hello.s file and try to execute clang -v hello.s -o hello again?

[asterite]

Or maybe to:

(I see all .def in the file start with _... so just in case...)

[Kelet]

Both String_cstr and _String_cstr work like a charm and print out "Hello World!"

[asterite]

Awesome!! :-)

So our first step is to have a different mangling for functions, at least for Windows. I'll think of something. I don't think replacing all non-alphanumeric characters to underscore will work, but it need to be thought a bit to avoid conflicts between definitions.

I'll let you know when I do this. In the meantime you can try to do it. The method that mangles a name is here, just in case you wonder or want to try to change it too.

[asterite]

@Kelet, can I ask you to try something else?

What happens if you use _String.cstr instead of _String_cstr? I'm trying to find out which characters are allowed...

[Kelet]

Yep, it works. Dollar signs, periods, and underscores should work according to the manual.

[Flaise]

Any progress on this issue? Crystal looks like exactly the kind of language I'd like to begin using for new projects but the lack of Windows support is a dealbreaker for me - Windows is where you find paying customers and I can't be investing myself in something that locks me out of having an audience.

[G4MR]

@Flaise yeah I agree, I'd love to try this on windows.

[bararchy]

So, Trying to build the Windows branch using the instructions in: https://github.com/manastech/crystal/blob/windows/README_win32.md

Step 1 produces:

 bin/crystal build src/compiler/crystal.cr --cross-compile "windows x86" --single-module --target "i686-pc-win32-gnu" --release -o bin/crystal
Error in ./src/file/stat.cr:81: undefined constant Stat

  fun stat(path : UInt8*, stat : Stat*) : Int32
                                 ^~~~

[bararchy]

Using @xwanderer fork from https://github.com/xwanderer/crystal/tree/win32
I get a similar issue regarding types

 bin/crystal build src/compiler/crystal.cr --cross-compile "windows x86" --single-module --target "i686-pc-win32-gnu" -o win32/crystal
Error while requiring "prelude"

in ./src/prelude.cr:17: while requiring "iterator"

require "iterator"
^

Syntax error in ./src/iterator.cr:194: type variables can only be single letters

  struct Zip(I1, I2, T1, T2)
             ^

[rishavs]

Just wanted to add my support to this. I really want to try out Crystal but not at the cost of my favored platform and environment.

[david50407]

And I'm going to support on this, too.
I'm trying to make the Crystal compiler run on Windows first, and go building std-lib on windows then.

[refi64]

@david50407 Well, the compiler is written in Crystal, so you kind of need to do both at the same time...maybe Cygwin could help there?

[david50407]

@kirbyfan64 I tried this way https://github.com/manastech/crystal/issues/26#issuecomment-40704994 , and run Hello world program well with LLVM 3.7 on Windows with TDM-GCC 5.1.0

Then I'm going to make Crystal compiler can be cross-compiled to Windows, for this, I will make a part of std-lib (core libs?) works that compiler needs.

EDIT: Or use Crystal to build LLVM code, use LLC to generate object file, but link with MSVC link works well, too.

[ozra]

So glad to see progress and interest on this front!

[mverzilli]

+1, it's great seeing someone brave enough to tackle this! <3

[anilreddy]

+1

[nob-suz]

+1 looking forward to see!, and there is recent LLVM Clang for MSVC&,NET http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/

[david50407]

It is a problem that Windows doesn't provide some POSIX Process calls, like fork(), getsid(), ...etc.

I saw the solution in Ruby, it decide to raise NotImplementedError and tell user "the function is unimplemented on this machine". ( https://github.com/ruby/ruby/blob/trunk/process.c#L3690 )

Should I do the same behavior like Ruby (, throws an Exception), when I cannot find the solution on Windows? (like Process.fork())
I think this will keep std-lib in the same interface (, that is, making std-lib more platform indepedent), and let coder (who codes in Crystal) to check the document and catch the Exception by their own (without causing error on compile-time).

But I don't know if raising Exception on runtime is better than throwing error on compile-time or not.
How about you guys think?

[jhass]

It should fail to compile IMO, either by calling raise in a macro or simply letting it run into an undefined call.

[lowjoel]

I think a compile-time error is more suitable, since Crystal is a compiled language, and we want to catch as many errors as early on as possible.

[david50407]

@jhass , I think raising NotImplementedExecption is better than undefined error.

Many languages does this on runtime, like Ruby, Python, Java, C# (even have NotImplementedException and NotSupporttedException), etc., they throw exceptions to keep the spec (or I mean the interface) of libs generally. (And it also make document auto-generating more easier.)

But we don't have VM in Crystal (, means we need to compile every time when generating other platform's executable files) , so we can just raise execption on compile-time.

And std-libs are not just C/lib bindings, they should make Crystal has a good interface to make coders build more portable applications.

[david50407]

I have one more problem when I'm trying to make compiler throws the exception on compile-time, does there any trick to show which method is 'not supported yet'?

for the code below:

macro raise_not_implement_yet_exception
  {% raise "Not Impl. yet" %}
end

class Foo
  def test
    raise_not_implement_yet_exception
  end
end

Foo.new.test

it's error like this:

Error in ./not_impl.cr:11: instantiating 'Foo#test()'

Foo.new.test
        ^~~~

in ./not_impl.cr:7: expanding macro

  raise_not_implement_yet_exception
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

in ./not_impl.cr:2: can't expand macro: Not Impl. yet

 {% raise "Not Impl. yet" %}
    ^~~~~

I think it doesn't point out which method is 'Not Impl. yet' clearly, and it looks like it's just a macro expansion error.

[bcardiff]

@david50407 you can puts in compile time. It does looks a bit better. http://play.crystal-lang.org/#/r/ml8

[Regarding runtime vs compile time] If the unsupported operations do not compile then the specs won't compile as a whole. I would prefer to have a flag that shows a progress regarding how much of the stdlib is supported in windows. But, this might be more a issue of spec. Yet, as things are right now, I would vote for runtime exceptions for this case. In the long term a compilation errors sounds better.

[lowjoel]

I have not used much Crystal, but how about something radical -- put the platform-specific functionality in a library/module/include (sorry...) that needs to be explicitly imported? I gather most of these functionality that can't be implemented on Windows is due to it being Unix syscalls, and it's likely that this would be all implemented, or not implemented at all.

There are some edge cases, like OS X not supporting anonymous semaphores and stuff like that, but I think that's a little easier to deal with.

[I initially followed this because I was short on time, and also I wanted to try to get this to work so I can experiment with the language at my leisure, sorry for being uninformed.]

[david50407]

@lowjoel, In Ruby, you still can call Process.fork() on Windows, but it will raise an exception; But in golang, it even don't have fork() call!
The question is: how to divide out which is platform-independent method and which is platform-specific method?
As I said, std-lib should be the interface that you and I can use the method without worrying about if this method is platform-independent or have to call in another way on different platform.

BTW, And Crystal seems to only compile the code we called not whole modules right now.

[david50407]

@bcardiff @lowjoel How about making these not/un-supported methods warn (, or just showing some message for now,) on compile-time, and raise on runtime.
Because we have spec written in Crystal, if we want to test the spec, we have to pass the compilation first, and check these methods raise normally.

[refi64]

Well, Ruby isn't an error since nothing is an error until you try it...so it isn't the best example...

Honestly, it should be a compile-time error. I can't think of a single case that it would actually be _desired_.

[david50407]

@kirbyfan64 which one you think is better? raise in macro or just let the method undefined?

[rishavs]

I would recommend not leaving it undefined.

[ozra]

If using unsupported functionality when compiling for a certain platform it should definitely error at compile time! And as many already mentioned, preferably with a more specific error "not implemented for this platform", rather than just "method missing".

[ysbaddaden]

Raising in macros is unsupported as of now. For now, please raise a specific exception at runtime eg: NotImplementedError). Specs will then show what needs to be implemented.

If a feature is impossible for a specific platform (eg: fork) then skip the method definition, so code won't compile. Please open an issue if it's not satisfactory —we could have @unsupported "message" just like it was proposed to have @deprecated "message", but that won't happen until we get near to 1.0

Also, please check the work by xwanderer on porting Crystal to windows, before restarting from scratch.

Last but not least, in order to avoid daily merge errors, it could be interesting to englob code, especially when the code is mostly about reimplementing than fixing for a platform:

# src/file.cr
ifdef windows
  require " windows/file"
else
# untouched source code
end

[david50407]

@ysbaddaden I'm merging master into xwanderer's win32 branch and upgrading the exist code to 0.9.1, so these methods are in single file now.

I'm going to open an issue for @unsupported "message", it is a great solution for marking unsupported methods IMO.

And I'll try to divide out the platform-specific codes. Will Linux, Mac OS X, and other platform we may support later be in this form in the future?

EDIT: Or should I create a new branch based on master and add codes in that form? (not merging xwanderer's code directly)

[ysbaddaden]

Your call. A windows port is a long task. I proposed to make as minimal as possible changes to the current code that is likely to change often, so your work won't be hard, if not impossible, to merge eventually and during all the development process.

The current code may eventually follow the same pattern, or not. That depends if other platforms are very different or if it's mostly a Windows vs Unix thing — libc bindings will eventually be generated automatically by crystal_lib from C headers so there is no need to extract them for each Unix platform.

[david50407]

We need SEH (Structured Exception Handling) for unwinding, and LLVM supported new intrinsics for windows from LLVM 3.8, but we are still using LLVM 3.5/3.6.

So we may wait for upgrading to 3.8/3.9 or I'll try other ways to use SEH. :cry:
Or we can wait for the new compiler (#1824) to using 3.8 or above lol

[asterite]

Until we support Windows, it seems it's possible to run it in the Ubuntu bash inside Windows: https://www.reddit.com/r/crystal_programming/comments/4m9fjd/i_got_crystal_to_install_in_the_ubuntu_bash/

[david50407]

@asterite :tada: But it seems that cannot use Windows API and creating some cool GUI applications :disappointed:

[asterite]

@david50407 True. That's why I don't understand why everyone wants Crystal for Windows. We'd need to bind the whole Windows API. I believe C# is a better language for that, as it also comes with Visual Studio and you have a visual editor, etc.

[xtagon]

I think what people really want is Ruby on Windows, but compiled instead of interpreted, so they look to Crystal.

[bcardiff]

I would expect to see Windows API if crystal compiler is able to get windows native support. Not in the std, but it will. AFAIK WFP is not Windows API, so it will be only for win32-ish apps. But still a long way to go.

[oprypin]

@asterite
Why everyone wants Crystal for Windows:

To be able to run programs on 99.9% of desktop computers, not 11.2% as it is now. [1]

And no, the fact that web applications don't require Windows to be served to Windows users does not console me. That is only one kind of application, and I am not interested in using Crystal for it anyway.

And using Windows API directly is not required to make GUI applications, that's for sure. That's not what people do these days.
Cross-platform library bindings for Crystal would start pouring in immediately.

[asterite]

What do users use Ruby for in Windows?

[david50407]

@asterite yes, C# is good on Windows, but we (maybe only me) just want this awesome language can run on Windows.
Why? Because it's so beautiful and amazing and I wants this also can be on Windows when I have to write something or create something :tada:
BTW, I guess if there is any possible can move to Windows or even Crystal only bind the minimal Windows APIs, there will also be many shards or modules come from communities (yeah, Open Source power :heart:).
Porting to Windows doesn't needs any GUI binding requirements on Crystal, but I believe there will be many bindings come out. (like Windows only's GDI+ or others)

[david50407]

@asterite I don't think "What do we use Ruby on Windows" is the problem we don't want to move Crystal to Windows, how about "What do we use Node.JS/Python/Java or other languages on Windows?"
I know there can be many answers and many way to do a program, but we love Crystal. :heart:

[asterite]

Yeah... maybe I rushed a bit with my answer. I haven't used Windows in years and I don't have good memories of using it, so that's why I'm not interested in Windows that much, but it'll definitely happen in the future.

[refi64]

I haven't used Windows in years and I don't have good memories of using it

You should try Windows 10. It's a pretty significant improvement over the crud MS has been releasing for the last several years. I mean, you can actually paste at the command prompt now!

[Flaise]

I don't have good memories of using [Windows]

I feel similarly but try telling that to my target audience. Would running a Crystal app from the new Windows Bash prompt be enough to start a GUI toolkit or SDL window?

[ysbaddaden]

@asterite why do want Ruby or Crystal on OSX? I mean, you'd have to bind the whole cocoa libraries, and such. Or maybe you just happen to use OSX and not Linux and don't want to bother with VMs?

To build cross platform applications (with GUI) one either have to write Java or Python or C++. It would be very nice to have Crystal as an alternative, using for instance a wxwidgets binding, that would happen to be identical on all platforms. Neat.

@Flaize no. It's CLI only and it can't access windows API.

[asterite]

You all have very good points. I'm convinced now that supporting Windows would be very nice to have :-)

[david50407]

BTW, Visual studio now provides APIs for developers to make other language's integrations, Node.js and Python now have support by Microsoft officially [1] [2] (was come out from communities).
If Crystal is going to land on Windows, it can also work with VS well. (by writing some VS extensions to interact with Crystal)
And, @asterite, we know that porting to other platforms is kind a hard work, thank to every contributors.

[ozra]

I haven't coded specifically for Win-UI in 15 years (and then only for clients, not my personal want), most of the time been using SDL, etc. Personally I loathe windows (I only have it on the machines in my music studio, clients usually have/want recordings in Cubase or so), but I think it's _very_ important that Crystal is available for it. Especially as @Flaise says: the target audience for a certain app doesn't necessarily share the values of the dev'er ;-)

There are many alternatives for UI: GTK, Qt, QT-QML and many others. Some go coders seem to go the QML-route, making the backend and frontend separate (like a web-app but QML instead), but there is a c-wrapper lib so it could probably be compiled in.

Anyways, that's that for UI's.

[rdp]

@Flaise I doubt it unless you have a working X windows server going as well (though I haven't checked into it, but might be windows 10 only, etc. etc.) but maybe work, that would be a convenient win :)

Also someone mentioned that possibly building dependencies is what's blocking it? https://github.com/crystal-lang/crystal/wiki/All-required-libraries

[omarroth]

I'm working on porting more complex programs to windows, and I'd like to present what I have so far. There are several windows ports of linux functionality, so there shouldn't be a copious amount of work writing platform-specific code. Binding to the windows API doesn't seem to be a problem. A sample program like this:

@[Link(ldflags: "-include windows.h")]
lib LibWin
  fun message_beep = MessageBeep (uType : UInt32) : Nil
end

and compiling on a linux machine with

crystal build --cross-compile --target i686-pc-windows --prelude=empty hello.cr

appears to work fine. I've made a few changes so that everything will link correctly. Compiling a smaller standard lib produces

$ gcc main.o -include windows.h -lgc-lib -lpthread -levent -lgw32c -L/usr/lib -L/usr/local/lib
Warning: resolving _GetLastError by linking to _GetLastError@0
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
main.o:(.text+0x161): undefined reference to `_tls_array'
main.o:(.text+0x196): undefined reference to `_tls_array'
main.o:(.text+0x7d1): undefined reference to `_tls_array'
main.o:(.text+0x7f4): undefined reference to `_tls_array'
main.o:(.text+0x812): undefined reference to `_tls_array'
main.o:(.text+0x84c): more undefined references to `_tls_array' follow
main.o:(.text+0x2c8d): undefined reference to `iconv_open'
main.o:(.text+0x38ec): undefined reference to `iconv_close'
main.o:(.text+0x3ad0): undefined reference to `iconv'
main.o:(.text+0x59c0): undefined reference to `GC_pthread_detach'
collect2.exe: error: ld returned 1 exit status

I'm having trouble finding where tls_array is called by the compiler, and the llvm docs don't seem to provide very much information on it either. I'm also not sure why GC_pthread_detach isn't being provided by gcc, although it's probably because I'm using MSYS for crystal but used VS to build bdwgc. However, all the other GC functions appear to work fine, so that's something.
I'm using LLVM 3.6 for both windows and linux build environments.

[refi64]

because I'm using MSYS for crystal but used VS to build bdwgc

Probably just the wrong bdwgc version. AFAIK all Windows compilers are C ABI compatible; it's with C++ that things get hairy.

[ysbaddaden]

Because pthreads are only available on POSIX platforms (hence the "p" I believe). You need to write an alternative Thread and GC integration specific to windows, using windows threads and whatever boehm-gc is providing.

[ysbaddaden]

Errata: the p stands for portable, but I don't think it includes anything but POSIX.

[rdp]

I typically use pthreads-win32 as a wrapper for it, though it lacks a few
things, perhaps it has enough...

On Sat, Jul 2, 2016 at 3:55 AM, Julien Portalier [email protected]
wrote:

Errata: the p stands for portable, but I don't think it includes anything
but POSIX.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/crystal-lang/crystal/issues/26#issuecomment-230093791,
or mute the thread
https://github.com/notifications/unsubscribe/AAAw0JULKi6DmmyGfFVEHjBS0VmDbt3qks5qRjV6gaJpZM4A-WFl
.

[asterite]

@omarroth tls_array seems to be a call LLVM is inserting for generating code for thread local storage, only for Windows. I don't know why, and what's that call in windows.

[david50407]

@omarroth did you solve the problem with error handling?

[omarroth]

@david50407 I think what I have should work, but I can't really test it until I can produce a working binary.

[dimavs]

I've managed to compile simple
puts "Hello!"
using mingw-w64

Linux box:

• added 'x86_64-w64-mingw' target to lib_c (pretty much x86_64-linux-gnu copy);
• dumped llvm byte code (_DUMP=1 ../crystal/.build/crystal build test.cr --cross-compile --target "x86_64-w64-mingw" --single-module 2> test.bc_)

Windows box:

• installed msys2/mingw-w64 environment
• _llc test.bc_
• _clang -c test.s_
• built mmap (https://github.com/witwall/mman-win32)
• _clang test.o stub.c -static -levent -lgc -lpthread -liconv -lws2_32 -lpcre -I. -L. -lmman_

_stub.c_ just a simple stub for _setup_sigfault_handler, fcntl, dladdr, pipe, waitpid_ (and I've actually commented out _abort_ on _fork_ check in _libgc_)

So, obviously, to support Windows all those famous _fork_ and _fcntl_ should be implemented. Not sure what status of _gnuwin32_ library is.
Also, just wondering what target we should point: mingw, cygwin or msvc?

[bcardiff]

IMO we should point for msvc. I feel is the more natural option for a windows developer.

Thanks for investing efforts for this

[omarroth]

@dimavs What happens when you try compiling something bigger? Maybe something like samples/sieve.cr. Or the compiler itself? _gnuwin32_ hasn't been updated since 2010, but I'm assuming that's because it's feature complete.

@bcardiff msvc seems reasonable. Any windows developers that would like to put in their 2c?

[sumproxy]

I'd vote for mingw although any windows support is really very much appreciated!

[RX14]

The final target should be windows without any external toolchains needed (i'm assuming that's what msvc is), although mingw or cygwin would be a useful first step that could get merged.

Would adding mingw or cygwin support help with "native" windows support?

[konovod]

Cygwin is terrible. It's more like emulator then native program. Personally i'll prefer mingw, but msvc is fine too.

[omarroth]

@RX14 Windows doesn't come with a C compiler like Linux does. msvc is comparable to xcode, which provides tools for building crystal. msvc is the closest you can get to "native" Windows support. Cygwin or MinGW are more focused on making code for Unix work on Windows systems, so while work on making crystal compatible with those targets might be helpful, it's likely only a small amount of work toward "native" windows support. Cygwin or MinGW may be adequate though.

@konovod I personally prefer Cygwin as it has a better package management system and includes mingw packages in their listing. I'm not sure how well they work, but I've had fewer problems downloading packages from Cygwin (like llvm, libgc) than building them on MinGW.

[RX14]

@omarroth does mingw allow you to create an executable file which doesn't depend on mingw? I assume cygwin would require you to depend on the cygwin DLLs in runtime. Whichever toolchain allows me to create the most native feeling binary for end-users to use is my favourite.

[omarroth]

@RX14 As far as I know, executables from both toolchains are standalone.

[sumproxy]

AFAIK cygwin has its own console and I think executables built with it will _not_ run in native windows console. Tell me if I'm wrong

[konovod]

@omarroth maybe i'm wrong (didn't used cygwin for long time), but i think mingw is actually a gcc ported to windows. It produces standalone executables that calls winapi directly. On the other hand, Cygwin executables require cygwin1.dll and they call it for any file access or sockets or threads creation. So it is a cygwin target to make porting unix programs easier (by adding a compatibility wrapper), while mingw is just working gcc, that is much better compiler (imho) than a microsoft msvc.

[sumproxy]

Cygwin DLL is mentioned on the frontpage of Cygwin project https://www.cygwin.com/:

The most recent version of the Cygwin DLL is 2.5.2.

[omarroth]

@sumproxy From the FAQ:

Can I build a Cygwin program that does not require cygwin1.dll at runtime?

No. If your program uses the Cygwin API, then your executable cannot run without cygwin1.dll. In particular, it is not possible to statically link with a Cygwin library to obtain an independent, self-contained executable.

So you are correct. The choice then comes down between MinGW and MSVC, whichever is more convenient for Windows devs and end-users.

[RX14]

I think we should start with MinGW, as it is easier to port to, then work on MSVC once that is complete.

[refi64]

I think we should start with MinGW, as it is easier to port to

AFAIK the only difference for Crystal's use case would be libraries.

[RX14]

@kirbyfan64 that's a rather large difference considering the amount of libraries crystal's runtime depends on.

[dimavs]

@omarroth Just tried sieve.cr - works fine. Don't think compiler itself would work.

About package management, msys2/mingw got perfect package management (pacman from arch linux), it's clean and simple (https://github.com/Alexpux/MSYS2-packages, https://github.com/Alexpux/MINGW-packages).

My personal preferences - msvc and mingw, cygwin is simpler (it's already got fork and fcntl implemented :-) ), but cygwin.dll as a dependence doesn't look right to me

PS http server didn't compile (complaining about type redefinition, single module?). And I can't use obj files generated on linux box, they've got refs to __tls_get_addr

@bcardiff yeah, msvc sounds right to me too. llvm/clang is quite mature on Windows and got msvc support (just compiled current trunk llvm without issues using visual studio 2015). I am planning to spend some time over weekend playing with it.

[ysbaddaden]

MinGW is an alternative to MSVC to produce windows binaries without a POSIX layer, unlike Cygwin that bundles one (cygwin.dll). So either is fine. Maybe both MinGW and MSVC are good, because one may not know anything about MSVC and using MinGW looks simpler to UNIX users?

The Cygwin and UWin roads are a dead end eventually, because it requires another dependency, have licencing issues, yet it may help to port the compiler to Windows while we port the core/stdlib to the Windows API?

[david50407]

I think we can both support MinGW and MSVC, but start from MinGW may be easier.

[rishavs]

Hi

Any updates?

[asterite]

@rishavs not yet

[rdp]

In terms of usefulness, yes, some of us have dev boxes that run windows and it'd be nice to be able to code our crystal apps "in native windows" and even deploy them there, at times (even command line apps). Cheers!

[andrewzah]

I got it working with the windows beta linux subsystem & bash. Just install a few things:

sudo apt-get build-essential lib32z1-dev libssl-dev libgmp3-dev

[exts]

@azah yeah, but that's still technically producing linux binaries, not really the same thing.

[andrewzah]

Right, but at least it lets windows users use crystal until something native comes along.

[rishavs]

@azah
a lot of us are actually using crystal that way. But unless we get windows compiling, I cant do anything but play around in Crystal. i am like a kid who was handed a present but told not to open it. T_T

[costajob]

Virtual machine + Vagrant?

[rishavs]

Dont know about Vagrant. will check it out.
Does it allow me to compile the binaries for a windows target?

[RX14]

@rishavs no, vagrant is just a virtual machine manager.

[rishavs]

Anything I can do to help?
I am at a beginner level, but have some free time.

If someone can list out the steps that need to be explored, i'd like to take a crack at it and report back.

I am assuming that I need to run crystal programs on Linux and get the .bc output. then run that through LLVM/LLC on windows. report everytime there is any error. is this correct?

[exts]

now that crystal has llvm support in 0.20.0, how hard would it be to get windows support going? I would totally contribute to a bounty on bountysource to get this going 👍

[RX14]

Crystal has always run on llvm, its the standard library which needs porting. The difficulty is that the standard library is built assuming the os is unix-based, which windows is not. The current best course of action seems to be to build using an existing "posix on windows" took chain like mingw.

[rishavs]

i really think msvc should be the way to go.
All development work in Windows is generally done using the ms toolsets.

[ysbaddaden]

@rishavs see my comment above: targetting Cygwin is the easiest solution to get started. It provides a POSIX command line environment (which Crystal expectes), along with a POSIX layer (which Crystal currently requires). An alternative could be to install MinGW (POSIX environment) and UWIN (POSIX layer) instead.

Once required libraries are installed or built for windows, we should be capable to cross-compile simple programs, and with some work (e.g.,: fix fiber context switch, unwinding maybe) we should be capable to port the compiler, so it runs on Windows. Then, and only then, shall we start porting the core and stdlib to the Windows API, in order to eventually get rid of the POSIX layer (Cygwin or UWIN); adding support for MSVC but not dropping support for MinGW (at least) so UNIX users can feel at home and not bother with how the hell does MSVC projects work.

I emphasize: porting to Cygwin should take a few days of work. Porting to the Windows API will require weeks of tedious hard work.

[rishavs]

@ysbaddaden

I fear i dont understand language backends well enough to add any insight.

Assuming Cygwin it is, how can we help? We really want Crystal to come over to Windows. Every single release, that's generally the first question out in the comments.

If you or any experienced crystal dev can break the plan into manageable tasks, we can pick them up based on our abilities.

From my side, I'll try to cross compile small programs in cygwin and report back in case of any failure.
I tried the same with llvm, but llvm turned out to be too heavy and difficult for my knowledge level.

[RX14]

The fiber context switch should be unchanged between unix and windows. It's x86_64 all the same right?

[lbguilherme]

@RX14 Actually no. The current context switch crashes on Windows because the ABI for which registers should or should not be saved is different.

---

I have some initial work on compiling to windows (Using crystal to produce .ll, wine clang.exe to produce .o and then MXE to do the linking and produce the final executable .exe, which can be run in wine, all done in a Linux environment. And I started to translate the stdlib to use WinAPI calls everywhere. It is very very initial, but I'll publish it in a fork this weekend so others can see/suggest/help.

[TechMagister]

Why not "just" cross-compiling using mingw64 (or mingw32) ?
-> cross compile llvm ( or download windows binaries )
-> cross compile bc ( clone repo and run mingw64-configure && mingw64-make )
-> create src/lib_c/x86_64-windows-gnu and translate stdlib
-> run mingw64-make to compile crystal

More or less :)

[RX14]

@TechMagister because without a posix emulation layer, you cannot "just" translate the stdlib. Using an existing posix emulation layer will be much easier than porting the whole stdlib to the windows API.

[ghost]

Today I could start gvim under the (ubuntu) linux subsystem on windows.

I tried KDE Konsole and gnome-terminal but there is some dbus problem which I am unsure how to solve - but since ubuntu itself works, crystal will work too. I even could compile ruby from source in this ubuntu linux subsystem which I found funny. :D

So for the time being, the crystal project could actually say that crystal works on windows (win 10) via the linux subsystem. But I think it is also possible to compile crystal from source as well - I'll give it a try this weekend or so and try to not forget to report here.

[sorenbug]

So, if I were to make a Crystal plugin for, say, IntelliJ, how would I handle users on Windows that don't have the Ubuntu subsystem installed? (For installing Crystal automatically.)

[RX14]

@TsundereBug the simple solution is don't support windows until we have a windows compiler out and working.

[shayneoAtNorwood]

To be blunt the "use linux-on-windows" solution is no solution at all, anymore than older "use wine on linux" hacks in other places was ever a solution. From a developer ergonomics perspective its only a step removed from "Run it in virtualbox"

[jtarchie]

There is no argument that says having native windows support would be awesome. It is just a time resource, as an OS project, delegating and prioritizing are important skillset. It helps with their own sanity, but also deliver the features they need.

The proposals for "linux-on-windows" are a great interim solution. It gives you something work with and get started with while others can work on the support for native windows. It is an open issue because this is difficult problem. Working soley on this would take the authors away from cool features, which they are providing to a substantial user base (like me), already.

For constructive feedback on this issue, saying it would be "nice" or "that is not a viable option" is not helpful. It does not help you help them accomplish your goal.

All the issuers above, spend some time and give back. Turn your "it would be nice" to "I tried and had an error". 👍

[watzon]

@shayneoAtNorwood I have to disagree as I've been running Crystal in WSL just fine and have found some workarounds, like my wsl-proxy that make it work with editors like VSCode. Not saying it's a perfect solution, but it does work in the interim.

[Wulfklaue]

Thanks @watzon for the link to wsl-proxy. I have been wondering for a while if it is possible to communicate with WSL from outside and the wsl-proxy trick is a nice solution for this issue.

[shayneoAtNorwood]

Right, but its not really an appropriate choice for shippable code, as WSL is specifically marked as a developer only option and requires lowering certain machine security standards regarding code signing and the like to install. For coder stuff, its fine. But I could not in good conscience ship something that relies on the windows linux subsystem because it would require them to put their machine into "developer" mode and reduce the effectiveness of windows built in hardening.

[watzon]

Well yeah, but for "dipping your toes in the water" so to speak WSL works
for now. As it is Crystal is still in beta anyways, so "shippable" code is
relative.

I do agree having the compiler work on windows would be great though. I
know that there is a PR that's a WIP right now, but it's only being worked
on by one person and could probably use some other contributors.

On Oct 22, 2017 10:44 PM, "shayneoAtNorwood" [e-mail]
wrote:

Right, but its not really an appropriate choice for shippable code, as WSL
is specifically marked as a developer only option and requires lowering
certain machine security standards regarding code signing and the like to
install.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/crystal-lang/crystal/issues/26#issuecomment-338553387,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEU0fmuirmNbgtTzgWFhoBXFGRYsyboVks5svCe9gaJpZM4A-WFl
.

[Wulfklaue]

Right, but its not really an appropriate choice for shippable code, as WSL is specifically marked as a developer only option and requires lowering certain machine security standards regarding code signing and the like to install. For coder stuff, its fine.

That might have been true a few weeks ago, but with Windows Fall Update, WSL is now a full featured option like hyper-v... No more beta, no more need to drop to "developer" mode.

https://blogs.msdn.microsoft.com/commandline/2017/10/11/whats-new-in-wsl-in-windows-10-fall-creators-update/

But I could not in good conscience ship something that relies on the windows linux subsystem because it would require them to put their machine into "developer" mode and reduce the effectiveness of windows built in hardening.

Shipping a final product on a language that is 0.23, is not exactly the smartest thing to do. Crystal is usable for your own development and your own hosting ( where you are in control of the environment ) but shipping a product written in a beta language, that is asking for trouble.

[ysbaddaden]

Please stop flooding about WSL!

This issue is about *adding support for Windows not about running crystal in whatever VM/emulation system.

We gradually had support, but Windows is still UNSUPPORTED.

[exts]

Thank you @ysbaddaden, no windows users care about VM's we want native support.

[SolarLune]

Yo, just wanted to pop in and pipe up. As a game developer, despite the fact that I like to work on Linux and Crystal's looking pretty great, most gamers are on Windows. So, Windows support would be needed for a supported target platform for me to be able to use Crystal for development.

[RX14]

Please, can we keep the comments to constructive comments with discussion about actually implementing this feature. We know how much the community wants this, we don't need any more comments which essentially translate to 👍.

[SolarLune]

I do agree with you, but considering that it's not an insignificant portion of people that believe that running Crystal on a bash VM is OK for now, it can't hurt to bring up another use case in which a fully compatible version of Crystal is absolutely necessary.

[mverzilli]

I second @ysbaddaden and @RX14. Please, stop asking for something that was already accepted and is one of the top project goals. If it hasn't happened just yet, it is because of lack of resources and time. It is slowly progressing though.

Verbalizing more requests for it to happen will only make this thread harder to follow and confusing for by-passers. Learn to take "yes" for an answer! :)

[sam0x17]

One more thing to consider: the second we get native windows support, there are a lot of people who are going to be interested in doing something like Electron but with crystal -- I have several friends working on desktop apps in Electron who would switch to crystal in a second if the cross platform support was there.

Not only that, but crystal is _perfect_ for doing little one-off command line utility programs, and windows support would just make that sweeter. Right now the best I can find as a cross platform solution for that is Node.js with node-pkg (or electron).

[RX14]

5339 has just been merged, which brings the ability to compile puts "Hello World" on native windows. Over the next few months it's likely people (including me) will PR in new support for more and more of the crystal standard library including networking, fibers, and evented IO. If people want to help with that effort, or want to "take" a piece of that work to work on themselves, please comment below.

[sorenbug]

I'm not against implementing concurrency on Windows, however I may not have the time or knowledge of current Crystal to do so.

When is this expected to be fully complete via development like this?

[RX14]

@TsundereBug that's hard to say, we'll never get "fully complete" since we can't implement fork(). It could be as low as a few months or as long as a year to get to "production ready" though.

[sam0x17]

@RX14 that is actually super exciting 🕺

[RX14]

Just FYI, windows coordination is now happening in #5430. Not sure when this issue should be closed, I guess most people would want to at least see a self-hosted compiler before closing this issue.