Get best of the week

OS "Sivelkiriya": contoh membangun program

Halo Habr.

Posting ini melanjutkan siklus publikasi tentang proyek OS Sivelkiriya. Artikel pertama dari siklus memberikan deskripsi umum konsep, yang kedua menjelaskan mengapa itu diperlukan dan dalam bentuk apa produk bisa melihat cahaya, yang ketiga menggambarkan solusi arsitektur, dan yang keempat menjawab pertanyaan tentang bagaimana mengoordinasikan tindakan pengembang OS dan Perangkat lunak dalam model ini. Artikel ini akan menunjukkan contoh memecah program sederhana menjadi modul-modul agar sesuai dengan realitas OS baru.

Pertimbangkan contoh klasik: program yang memungkinkan Anda untuk membuka file yang berisi gambar bitmap dan melihatnya di layar. Gambar dapat diskalakan, dan jika ukurannya pada skala saat ini melebihi ukuran layar, gulir.

Dalam sistem operasi modern, masalah ini sering diselesaikan dengan aplikasi dengan arsitektur tertutup, yaitu salah satu yang berisi semua kode yang diperlukan, atau menggunakan komponen pihak ketiga murni atas inisiatifnya sendiri. Poin kuncinya adalah Anda tidak dapat menggunakan bagian dari aplikasi - Anda bisa memulainya seperti apa adanya atau menggunakan solusi lain.

Untuk memahami bagaimana masalah ini diselesaikan dalam kerangka OS Sivelkiriya, pertama-tama Anda harus melihat "di balik tudung" dari program ini dan memahami apa yang dilakukannya dan konsep-konsep apa yang beroperasi dengannya. Berikut ini adalah entitas yang muncul selama pengoperasian program.

  1. Lokasi gambar.Dalam kasus klasik, ini dijelaskan oleh path ke file pada disk. Dengan sedikit pertimbangan yang lebih luas, alamat di jaringan lokal atau di Internet juga termasuk dalam kategori ini. Namun, ini tidak menguras semua kemungkinan: gambar dapat ditemukan dalam RAM, pada output beberapa program (misalnya, prosesor foto atau penyaji grafis), pada halaman web, dalam obrolan atau pesan email, di dalam arsip atau dokumen kantor. Terlepas dari kenyataan bahwa secara teknis semua opsi ini berbeda satu sama lain dan memerlukan pemrosesan yang berbeda, dari sudut pandang pengguna mereka semua melayani satu tujuan: mereka menunjukkan di mana gambar yang ingin dilihatnya berada. Membuat antarmuka yang memungkinkan Anda untuk memilih di antara begitu banyak opsi adalah tugas yang tidak sepele, tetapi secara konsep tidak ada hambatan untuk pendekatan ini.Selain itu: tidak ada alasan mengapa pengguna tidak boleh diberi kesempatan untuk melihat gambar yang terletak di salah satu lokasi di atas.
  2. , . , , , .
  3. . , , jpeg gif. : jpeg .gif, gif . , , , , web-.
  4. , ( ) .
  5. . , tiff, . β€” , gif β€” .
  6. .
  7. : , , , .
  8. .
  9. ( ) , .
  10. ( ), .

Dalam OS Sivelkiriya, masing-masing entitas yang tercantum di atas dijelaskan oleh antarmuka data tertentu. Representasi semacam itu memungkinkan penggunaannya dalam banyak konteks di luar model asli (yang akan dibahas kemudian).

Setiap antarmuka diimplementasikan oleh beberapa objek, yang dibuat oleh beberapa modul. Kode metode objek dieksekusi dalam kerangka kerja modul yang menghasilkannya. Pada saat yang sama, tidak benar untuk berbicara tentang meluncurkan modul sebagai aplikasi terpisah, karena mereka tidak memiliki utas sendiri, atau memori di luar objek yang dibuat oleh mereka. Jika Anda perlu menyimpan keadaan yang melampaui bekerja dengan satu gambar, itu disimpan dalam objek yang terpisah, akses yang dilakukan sesuai dengan aturan umum - melalui antarmuka objek OS.

Struktur modul yang terlibat dalam pekerjaan program ini mungkin terlihat seperti ini:

  1. Modul pertama mendefinisikan perilaku objek yang mengimplementasikan antarmuka "Lokasi objek" (gambar adalah kasus khusus objek). Secara khusus, ini menentukan cara mengakses byte dari lokasi tertentu. Namun, ia dapat menggunakan modul yang menyediakan akses langsung ke disk atau dukungan jaringan, tergantung pada lokasi fisik objek.
  2. Modul kedua menyediakan akses langsung ke byte gambar. Selain itu, ia memberikan petunjuk tentang kemungkinan jenis konten berdasarkan metode penyimpanan (ekstensi file, header server web, dll.).
  3. Modul ketiga, menggunakan petunjuk tentang jenis konten dan akses ke representasi byte-nya, menentukan jenis konten yang sebenarnya (format file gambar).
  4. , ( , , ) ( ) . , : , . β€” : jpeg .
  5. , , , , . β€” β€” , , .
  6. , . , . β€” , , , , , , , .

Tentu saja, selain modul yang dijelaskan, program dapat mengambil bagian dalam modul yang menyediakan fitur tambahan: logging, rendering komponen jendela, umpan balik audio, dan sebagainya.

Sangat mudah untuk melihat bahwa struktur seperti itu membuat penggunaan kembali fungsi yang diimplementasikan sesederhana mungkin. Jadi, memasang codec baru di sistem berarti jenis gambar ini akan secara otomatis didukung di semua konteks dan di semua program. Modul yang berbeda dapat ditulis oleh programmer yang berbeda dan dalam bahasa yang berbeda, namun, dalam kerangka model interaksi ini, perbedaan ini tidak signifikan. Satu dan codec yang sama dapat digunakan untuk memuat gambar ke layar dalam antarmuka ini, dan untuk merendernya dalam program pengiriman pesan, browser, penampil direktori, dan sebagainya.

Dukungan untuk kasus penggunaan baru dilakukan secara elemen. Misalnya, menambahkan beberapa antarmuka tambahan memungkinkan Anda untuk mendukung tindakan seperti pindah ke gambar berikutnya dan sebelumnya (terlepas dari lokasi mereka dan cara mengaksesnya) atau menerapkan filter. Pengenalan thin client juga bukan masalah: karena bagian data dan panggilan melalui batas modul dikendalikan oleh sistem operasi, dimungkinkan untuk mentransfer operasi yang mahal (misalnya, mendekode konten file dan menskala gambar) ke mesin lain.

Karena prototipe dari semua modul yang dijelaskan di atas diketahui oleh sistem operasi, ia tahu tentang kebutuhan mereka dari sudut pandang sistem dan dapat bertindak sesuai. Misalnya, operasi penskalaan gambar dapat dilakukan dalam utas terpisah sehingga bekerja dengan gambar besar tidak memblokir antarmuka pada komputer kelas bawah. Selain itu, karena modul tidak membuat asumsi tentang utas di mana mereka dieksekusi, optimasi tambahan dimungkinkan: misalnya, utas antarmuka pengguna dapat dipisahkan dari utas yang bertanggung jawab untuk komputasi (dalam hal ini, penskalaan), hanya jika yang terakhir Saya tidak punya waktu untuk menyelesaikan pekerjaan dalam periode waktu yang telah ditentukan, dan dengan skala ulang cepat, menggambar gambar pada skala baru dapat dimulai dalam aliran tambahan bahkan sebelumsebagai utas yang terlibat dalam rendering, yang tidak perlu lagi diselesaikan, ia akan memproses sinyal sampai selesai. Karena sistem operasi memiliki informasi tentang semua utas yang berjalan, tentang pemuatan dan kemampuan aktual dari prosesor komputer, data pengoptimalan dapat lebih efektif daripada yang dapat dilakukan penulis aplikasi terpisah berdasarkan asumsi tentang lingkungan pelaksanaannya.

Pertanyaan tentang bagaimana modul yang bersama-sama memberikan solusi untuk masalah yang diterapkan dihubungkan bersama-sama dapat diselesaikan dengan beberapa cara. Misalnya, jelas bahwa pilihan modul yang membaca byte file dari disk ditentukan oleh sistem file bagian ini, dan dalam semua kasus akses ke bagian yang sama, modul yang sama akan digunakan. Modul yang bertanggung jawab untuk menentukan format gambar kemungkinan akan dipasang pada level sistem dan digunakan dalam semua konteks. Pengecualian mungkin terjadi ketika modul gagal: dalam kasus ini, sistem operasi dapat mencari modul terpasang lainnya yang cocok dengan prototipe ini, dan jika ada, coba gunakan dengan input data yang sama. Lewat sini,kesalahan dapat diproses tanpa campur tangan pengguna, dan data tentang hal itu dikumpulkan dan, jika diizinkan oleh kebijakan keamanan mesin ini, diteruskan ke pengembang modul masalah bersama dengan informasi terkait yang diperlukan. Jika modul sering mengalami masalah, sistem operasi dapat memutuskan untuk mengeluarkannya dari rantai pencarian atau menurunkan prioritas di dalamnya.

Dalam kasus lain, pilihan modul dapat ditentukan oleh pengguna dan disimpan dalam konfigurasi. Jadi, modul penskalaan gambar yang berbeda dapat memberikan gaya render yang berbeda (parameter anti-aliasing saat memperkecil atau mengaburkan batas piksel saat meningkat). Tergantung pada konteksnya, pengguna mungkin perlu pendekatan yang berbeda (batas piksel tajam untuk penentuan posisi yang tepat atau buram untuk kenyamanan visual).

Metode untuk memulai modul juga bervariasi. Misalnya, modul yang bertanggung jawab untuk rendering jendela penampil gambar dapat dipanggil oleh modul yang bertanggung jawab untuk rendering desktop (dengan mengklik pada file grafik pada desktop), atau dengan modul yang menampilkan menu peluncuran program. Setelah memulai, modul jendela memuat modul-modul yang dibutuhkan untuk menyelesaikan tugas saat ini.

Deskripsi ini hanyalah demonstrasi kemungkinan mendasar dari penerapan skema interaksi seperti itu dan tidak dapat dianggap sebagai instruksi lengkap untuk menulis gambar viewer, sistem operasi dan / atau modul untuk itu.

Artikel sebelumnya dalam seri ini tersedia di sini: satu , dua , tiga , empat. Teks lengkap, seperti sebelumnya, tersedia di situs web proyek .

More articles:


All Articles