Sử dụng Windows cho các dịch vụ Unix (tiếp)

Xem lại phần I

Windows và Posix cũng chia sẻ một môi trường lệnh chung, vì vậy bạn có thể gọi Windows từ bên trong Unix shell đơn giản bằng việc gọi thi hành giống như bạn sẽ từ bất kỳ một dấu nhắc lệnh nào. Đổi lại cũng như vậy như là việc sử dụng “1s” để gọi thư mục kiểu Unix bằng cách liệt kê từ bên trong trình lệnh CMD. Nhưng nếu bạn cần toàn bộ Posix (bao gồm việc ánh xạ các file và tương tự như vậy) thì bạn cần phải sử dụng lệnh POSIX.EXE như load đầu vào cho lệnh kiểu Unix để tạo một môi trường đầy đủ.

Một vùng không kết nối ở đây là trong các dịch vụ nền: Posix bao gồm các kịch bản khởi động bản thân nó /etc/init.d và lịch trình cron hoàn toàn độc lập với dịch vụ Windows và lịch trình nhiệm vụ. Sự thử nghiệm thể hiện rằng là hoàn toàn có thể khởi chạy một vài dịch vụ Unix như các dịch vụ Windows giả mạo bằng việc sử dụng tiện tích "instsrv" từ Windows Resource Kit và "psxrun" (POSIX.EXE với tháo bỏ các chức năng I/O kết cuối) mặc dù đây là cách hack thô thiển nhất. Sẽ rất tốt nếu Microsoft có thể tìm được một wApart từ các thành phần cơ bản. SFU cũng bao gồm các điểm của các tiện ích Unix cũ cũng như các công cụ mới cần thiết cho biên dịch những lệnh mới bằng các công cụ GNU giống như gee và gmake. Màn hình dưới đây thể hiện nội dung của thư mục /bin trong cài đặt mặc định và một vài update.

Phụ thuộc vào bạn sử dụng SFU hay SUA mà các công cụ sẽ thực hiện gói cài đặt trực tiếp (SFU) hay sẽ dowload từ kho của Microsoft như một phần của quá trình cài đặt.

Interop Systems, một công ty được thành lập bởi các nhân viên gốc của Softway Systems cũng duy trì các port của một vài ứng dụng mã nguồn mở. Một vài gói có thể update đơn giản các tiện ích của SFU và SUA.c Nhưng Interop Systems lại duy trì các port khác với các ứng dụng chính giống như OpenSSH và Apache… Interop Systems tính một lần lệ phí là 20$ cho việc truycập đến các kho lưu trữ của nó.

Bạn cũng có thể thử tại các ứng dụng port bằng việc sử dụng các công cụ phát triển (hay các phiên bản update từ Interop Systems). Theo kinh nghiệm của chúng tôi, điều này có thể làm cho một vài thứ trở lên dễ dàng trong khi các ứng dụng khác là rất khó khắn với nó. Nói chung, nếu tarball nguồn sử dụng kịch bản GNU configure hỗ trợ Interix như một platform và ứng dụng không muốn làm việc trực tiếp với các tài nguyên Unix rõ ràng như /etc/passwd thì bạn có một cơ hội tốt để biên dịch thành công ứng dụng mặc dù nó vẫn không chạy. Nếu ứng dụng được viết đến các platform đích rõ ràng và nó không hỗ trợ cho Interix như một target thì bạn có thể không có được nó trừ khi bạn tốn nhiều ông sức để hack code.

Như ví dụ mẫu ở trên, chúng tôi có thể có được phiên bản mới nhất của Berkeley DB để biên dịch và chạy không có vấn đề gì. Chúng tôi cũng có thể có được SpamAssassin và các modul hỗ trợ khác để biên dịch và chạy (bao gồm Net::LDAP, mặc dù chúng tôi phải nâng cấp Perl từ Interop Systems). Vài modul của Perl khác sẽ không dịch hay sẽ không qua giai đoạn "make test". Khi chúng tôi không có được các thư viện CMU SASL để biên dịch, trong khi đó UW IMAPD và Cyrus IMAP lại được viết cho các platform cụ thể mà không hỗ trợ cho Interix. Vì vậy chúng tôi không thể biên dịch được với chúng.

Ở đây chúng tôi có hai ứng dụng Unix quan trọng mà chúng tôi thực sự cần cho hệ thống này là OpenSSH và Squid, và chúng tôi đã dễ dàng sử dụng các dịch vụ Windows cho các thứ ứng dụng khác. Trong vài trường hợp, giống như quản lý máy in chúng tôi đã sai lệch đôi chút với các ứng dụng Windows. Khi OpenSSH và Squid là có sẵn từ Interop Systems thì nó thực sự là dễ dàng. Ngắn gọn hơn là chúng tôi có thể chạy các ứng dụng mã nguồn mở tốt dưới Windows như chúng vẫn từng chạy trên Unix, và đây là một lợi ích từ việc tích hợp chặt chẽ với môi trường Windows.