←back to thread

Microsoft and Canonical partner to bring Ubuntu to Windows 10

(www.zdnet.com)
535 points raddad | 4 comments | 30 Mar 16 11:12 UTC | HN request time: 0.689s | source
Show context
jwildeboer ◴[30 Mar 16 13:11 UTC] No.11388953[source]▶
Project Janus reloaded? AFAICS it's the same approach. Some shim layer that translates between Linux kernel API and native Windows API. http://www.cnet.com/news/suns-solaris-10-to-run-linux-apps-t...!
replies(3): >>11390445 #>>11390708 #>>11391270 #
1. wyldfire ◴[30 Mar 16 16:49 UTC] No.11390708[source]▶
Maybe the NT kernel could gain a linux-syscall-compatible layer, instead of adding compatibility in userspace. That would allow for compatible (same-arch) binaries!

(EDIT: this would also require ELF loaders and all kinds of other good stuff, but still a possibility IMO)

replies(2): >>11390863 #>>11416933 #
2. Revik ◴[30 Mar 16 17:02 UTC] No.11390863[source]▶
Guess what, there actually is an ELF loader in the compatibility layer: https://pbs.twimg.com/media/CcTwejAUEAAq_jR.jpg
replies(1): >>11417545 #
3. JdeBP ◴[03 Apr 16 18:00 UTC] No.11416933[source]▶
> Maybe the NT kernel could gain a linux-syscall-compatible layer [...]. That would allow for compatible (same-arch) binaries!

What makes you think "maybe"? This is (reportedly) exactly what's happening. What did you infer was happening from the headlined article?

4. JdeBP ◴[03 Apr 16 20:37 UTC] No.11417545[source]▶
One (more) thing that is conspicuously glossed over is non-ELF executables. We've seen Win32 programs invoking ELF64 binaries demonstrated. And of course the Windows NT Linux subsystem already "knows" that it's a Linux subsystem process when a program comes to exec() a script, and doesn't have to worry about checking binary formats over fork() because the program image doesn't change. But missing so far has been Win32 programs invoking Linux executable scripts, that have #! lines.