API ve ABI Kavramları Üzerine

Yazılımların tüm mimarilerde çalışması ve geriye doğru uyumlu (backward compatibility) olması en çok istenen özelliklerdir. Geliştirilen yazılımın belirli bir dağıtım veya mimariye bağımlı olmayıp, taşınabilir olması büyük kolaylık sağlayacaktır. Sistem seviyesinden bakıldığında taşınabilirlikle ilgili 2 farklı özellik bulunması gerekir. Bunlar;
  • Application Programming Interface (API)
  • Application Binary Interface (ABI)
Şimdi sırasıyla bu kavramları inceleyelim;

ABI ( Application Binary Interface )

ABI, yazılım bileşenleri arasında belirli bir mimari için amaç dosyalar (object file) arasında arayüz  (interface) tanımlamaktadır. ABI demek ayrı ayrı derlenmiş modüllerin bir arada çalışabileceklerine dair alt seviyeli ve detaylı teknik kurallar bütünüdür. ABI uygulama bileşenleri arasında makine kodu seviyesinde uyumluluğu sağlar. Bu uyum korunduğu müddetçe aralarında etkileşim bulunan yazılım bileşenlerinin arka planı değişse de yeniden derlenmeye ihtiyaç duymaksızın eskisi gibi kulanmaya devam ederler.

  • Fonksiyonların nasıl çağrılacağı (calling convention), 
  • Parametrelerin nasıl geçirileceği, 
  • Yazmaçların kullanım şekilleri,
  • Sistem çağrılarının gerçekleştirilme biçimi, 
  • Amaç dosyaların bağlanması (linklenmesi), 
  • Amaç (object dosya) formatı gibi konular ABI kavramı içerisinde değerlendirilebilir. 
Yazılım geliştirme sürecinde ABI kavramı çok karşımıza çıkmaz. Kullanılan geliştirme araçları hedef platform için belirlenen ABI kurallarına uygun kod üretirler. Alt seviye işler yapanlar için bu genelleme doğru değildir. Sistem düzeyinde kod geliştirmek isteyenlerin üzerinde çalıştığı ve diğer çalışmasını istediği sistemlerin ABI standartlarını bilmesi gerekir.


API ( Application Program Interface )

API, uygulamaların kaynak kod seviyesinde birbirleriyle iletişim kurabilmelerine imkan sağlayan, önceden kararlaştırılmış arayüzler (interface) olarak tanımlanabilir. Genellikle her bir API, daha karmaşık ve alt seviye detaylar içeren bir sürecin, çeşitli arayüzlerle (fonksiyon çağrıları gibi) soyutlanmasını sağlar. Bu şekildeki bir soyutlama üzerinden kullanılan API'yi hizmet olarak veren yazılım bileşenleri güncellense ve alt tarafta yapılan işlemlerle ilgili yöntemler değiştirilmiş bile olsa, API seviyesinde aynı arayüz sağlandığı müddetçe bu API'yi kullanan uygulamalar için bir değişiklik yapılmasına gerek olmayacaktır.




Kısaca bir yazılımın, kullandığı kütüphanelerin,servislerin sonraki versiyonlarında herhangi bir değişikliğe gitmek zorunda kalmadan problemsiz çalışabilmesini sağlayan bir arayüz tanımlanması API kavramının ürünüdür.

Çevre Değişkenlerine Neden Gereksinim Duyulmaktadır

5:55 AM

Çevre değişklenlerine programlamadan da aşina olduğumuz işletim sistemi düzeyindeki global değişkenler gibi bakılabilir. Programlar birtakım dosyaları vs. bazı çevre değikenlerinin belirttiği yerde arayabilirler. Örneğin bir veritabanı dosyası DATABASE isimli bir çevre değişkeninin belirttiği dizinde aranabilir. Bu durumda programcı önce getenv 


fonksiyonuyla bu çevre değişkeninin değerini alır ve dosyayı o dizinde arayabilir. Veritabanı dosyası başka dizine yerleştirmek istenirse tek yapılacak şey bu çevre değişkeninin değerini değiştirmektir. Örneğin pek çok C derleyicisi <...> biçiminde include edilmiş dosyaları INCLUDE isimli bir çevre değişkenin belirttiği dizinde aramaktadır. Eğer bu çevre değişkeni set edilmemişse default bir dizin kullanılmaktadır. Ya da örneğin Java'da çeşitli jar dosyaları ve derlenmiş dosyalar CLASSPATH isimli bir çevre değişkenine bağlı olarak aranmaktadır. Bazı çevre değişkenlerini ise doğrudan işletim sistemi kullanmaktadır. (Örneğin PATH gibi, LD_LIBRARY_PATH gibi). 

Linux çevresel değişkenleri örneği


Windows çevresel değişkenleri örneği

Bazı çevre değişkenleri işletim sistemini hakkında bilgi vermektedir. Örneğin Windows hangi dizine yüklenmiştir? O anda kullanılan yerel ayarlar nelerdir? Kullanıcının ismi nedir? Home dizini hangisidir gibi bilgiler çevre değişkenleri aracılığıyla alınabilmektedir. Çevre değişkenleri proseslerarası haberleşmede de bazen kullanılabilmektedir. Örneğin, üst proses belli bir çevre değişkenini set ederek alt prosesi çalıştırır. Alt proses böylece o çevre değişkeninden bilgi alabilir. Böylesi basit bilgi aktarımı için herhangi bir proseslerarası haberleşme yönteminin kullanılmasına gerek kalmadan aktarılmış olur.


İşletim Sistemlerinin GUI Ortamlarında Mesaj Tabanlı Çalışma Modeli

2:31 AM ,
Mesaj tabanlı programlama modelinde klavye ve fare gibi aygıtlarda oluşan girdileri (event'leri) programcı kendisi almaya çalışmaz. Ya da pooling mekanizması gibi bir mekanizma ile girdinin oluşup oluşmadığını kontrol etmeye çalışmaz. Fare gibi, klavye gibi girdi aygıtlarını işletim sisteminin (ya da GUI alt sistemin) kendisi izler. Oluşan girdi olayı hangi pencereye ait ise işletim sistemi ya da GUI alt sistemi, bu girdi olayını “mesaj” adı altında bir yapıya dönüştürerek o pencerenin ilişkin olduğu (pencereyi yaratan) programın “mesaj kuyruğu (message queue)” denilen bir kuyuk sistemine yerleştirir. Mesaj kuyruğu içerisinde mesajların bulunduğu FIFO (First in First outprensibiyle çalışan bir kuyruk veri yapısıdır.  Sistemin daha iyi anlaşılması için süreci maddeler halinde özetleyelim:

  1. Her programın (ya da thread’in) “mesaj kuyruğu” denilen bir kuyruk veri yapısı vardır. Mesaj kuyruğu işletim sisteminin ya da GUI mekanizmasının bıraktığı mesajlardan oluşmaktadır.
  2. İşletim sistemi ya da GUI alt sistem gerçekleşen girdi olaylarını “mesaj (message)” adı altında bir yapı formatına dönüşürmekte ve bunu pencerenin ilişkin  olduğu programın (ya da thread’in) mesaj kuyruğuna eklemektedir.
  3. Mesajlar ilgili olayı betimleyen ve ona ilişkin bazı bilgileri barındıran yapı (structure) nesleridir. Örneğin Windows’ta mesajlar MSG isimli bir yapıyla temsil edilmişleridir. Bu yapının elemanlarında mesajın ne mesajı olduğu (yani hangi olaydan dolayı gönderildiği) ve olaya ilişkin gerekli bilgiler bulunur.

Görüldüğü gibi GUI programlama modelinde girdileri programcı elde etmeye çalışmamaktadır. Girdileri bizzat işletim sisteminin kendisi ya da GUI alt sistemi elde edip programcıya mesaj adı altında iletmektedir. GUI programlama modelinde işletim sisteminin (ya da GUI alt sistemin) oluşan mesajı ilgili programın (ya da thread’in) mesaj kuyruğuna eklemenin dışında başka bir sorumluluğu yoktur. Mesajların kuyruktan  alınarak işlenmesi ilgili programın sorumluluğundadır. Böylece GUI programcısının mesaj kuyruğuna bakarak sıradaki mesajı alması ve ona uygun işlemleri yapması gerekir. Bu modelde programcı kodunu şöyle düzenler: 
  • Bir döngü içerisinde sıradaki mesajı kuyruktan alma, 
  • Onun neden gönderildiğini belirleme,
  • Uygun işlemleri yapma, 
  • Kuyrukta mesaj yoksa da blokede bekleme
İşte GUI programlarındaki mesaj kuyruğundan mesajı alıp işleyen döngüye "mesaj döngüsü (message loop)" denilmektedir. Tipik bir GUI programında programcı bir döngü içerisinde mesaj kuyruğundan sıradaki mesajı alır ve işler. Mesajın işlenmesi ise “önce ne olmuş onu anlama ve ben buna karşı ne yapmalıyım?” biçiminde oluşturulmuş olan kodlarla yapılmaktadır. Pekiyi bir GUI programı nasıl sonlanmaktadır? İşte pencerenin sağındaki veya solundaki X (çarpı) simgesine kullanıcı tıkladığında işletim sistemi ya da GUI alt sistem bunu da bir mesaj olarak o pencerenin ilişkin olduğu prosesin (ya da thread’in) mesaj kuyruğuna bırakır. Programcı da kuyruktan bu mesajı alarak mesaj döngüsünden çıkar ve program sonlanır.


GUI ortamımız ister .NET, ister Java, ister MFC, isterse Qt olsun, işletim sisteminin ya da GUI alt sistemin çalışması hep burada açıklandığı biçimde gerçekleşir. Yani örneğin biz .NET'te ya da Java'da işlemlerin sanki başka biçimlerde yapıldığını düşünebiliriz. Aslında işlemler bu ortamlar tarafından aşağı seviyede yine burada anlatıldığı gibi yapılmaktadır. Sadece bize yalıtılmış bir ortam sunulmaktadır. Bu ortamlar (frameworks) ya da kütüphaneler çeşitli yükleri üzerimizden alarak bize daha rahat bir çalışma modeli sunarlar. Şimdi GUI programlama modelindeki mesaj kavramını biraz daha inceleyelim. Yukarıda da belirttiğimiz gibi bu modelde programcıyı ilgilendiren çeşitli olaylara mesaj denilmektedir. Örneğin klavyeden bir tuşa basılması, pencere üzerinde fare ile tıklanması, pencere içerisinde farenin hareket ettirilmesi gibi olaylar hep birer mesaj oluşturmaktadır. İşletim sistemleri ya da GUI alt sistemler mesajları birbirinden ayırmak için onlara birer numara karşılık verirler. Örneğin Windows’ta mesaj numaraları WM_XXX biçiminde sembolik sabitlerle kodlanmıştır. Programcılar da konuşurken ya da kod yazarken mesaj numaralarını değil, bu sembolik sabitleri kullanırlar. (Örneğin WM_LBUTTONDOWN, WM_MOUSEMOVE, WM_KEYDOWN gibi) Mesajların numaraları yalnızca gerçekleşen olayın türünü belirtmektedir. Oysa bazı olaylarda gerçekleşen olaya ilişkin bazı bilgiler de söz konusudur. İşte bir mesaja ilişkin o mesaja özgü bazı parametrik bilgiler de işletim sistemi ya da GUI alt sistem tarafından mesajın bir parçası olarak mesajın içerisine kodlanmaktadır. Örneğin Windows’ta biz klavyeden bir tuşa bastığımızda Windows WM_KEYDOWN isimli mesajı programın mesaj kuyruğuna bırakır. Bu mesajı kuyruktan alan programcı mesaj numarasına bakarak klavyenin bir tuşuna basılmış olduğunu anlar. Fakat hangi tuşa basılmıştır? İşte Windows basılan tuşun bilgisini de ayrıca bu mesajın içerisine kodlamaktadır. Örneğin WM_LBUTTONDOWN mesajını Windows farenin sol tuşuna tıklandığında kuyruğa bırakır. Ayrıca basım koordinatını da mesaja ekler. Yani bir mesaj oluştuğunda yalnızca o mesajın hangi tür bir olay yüzünden oluştuğu bilgisini değil aynı zamanda o olayla ilgili bazı bilgileri de kuyruktaki mesajın içerisinden alınabilmektedir.

GUI programlama modelinde bir mesaj oluştuğunda o mesajın bir an evvel işlenmesi ve akışın çok bekletilmemesi gerekir. Aksi takdirde programcı kuyruktaki diğer mesajları işleyemez bu da “kullanıcı açısından program donmuş etkisi” yaratmaktadır. Eğer bir mesaj alındığında uzun süren bir işlem yapılmak isteniyorsa bir thread oluşturulup o işi o thread’e devretmek ve böylece mesaj döngüsünün işlemesini sağlamak gerekir. GUI programlama modellerinde genel olarak mesaj kavramı pencere kavramıyla ilişkilendirilmiştir. Yani bir pencere yaratılmadıktan sonra bir mesajın oluşma durumu da yoktur. Bu nedenle mesaj döngüsüne girmeden önce programcının en az bir pencere yaratmış olması gerekir. Windows gibi bazı sistemlerde pencereler thread’lerle ilişkilendirilmiştir. Bu sistemlerde prosesin tek bir mesaj kuyruğu yoktur. Her thread’in ayrı bir mesaj kuyruğu vardır. Bu durumda işletim sistemi ya da GUI alt sistem bir pencereye ilişkin bir işlem gerçekleştiğinde o pencerenin hangi prosesin thread’i tarafından yaratılmış olduğunu belirler ve mesajı o thread’in mesaj kuyruğuna bırakır. Böylece biz bir thread oluşturup o thread’te de bir pencere yaratmışsak artık bizim de o thread’te o pencerenin mesajlarını işlemek için mesaj döngüsü oluşturmamız gerekir. Tabii eğer thread’imizde biz hiçbir pencere oluşturmamışsak böyle bir mesaj döngüsünü oluşturmamıza da gerek yoktur. Örneğin Microsoft işletim sisteminde bir thread bir pencere yaratmışsa böyle thread’lere “GUI thread’ler” yaratmamışsa “worker thread’ler” denilmektedir.



İşletim Sistemlerinin GUI Alt Sistemlerine Genel Bakış

6:06 AM ,

Bilgisayar sistemlerine terminal ile bağlanılması 1957 yıllına denk gelmektedir. Bu yıldan itibaren programcılar bilgisayarlarla klavye ve ekran yoluyla doğrudan etkileşim içerisine girmeye başlamıştır. Programcılar bilgisayarlarla text tabanlı olarak etkileşim haline girmişlerdir. Bu tür text tabanlı ekranlara konsol (console) ekranları da denilmektedir. 80’li yılların başında IBM ilk kişisel bilgisayarları çıkarttığında DOS işletim sistemi grafik bir arayüze sahip değildi. Daha sonra Microsoft da Machintosh sistemleri gibi (Machintosh sistemleri ilk grafik arayüz kullanan sistemlerdir.) Windows sürümleriyle birlikte grafik arayüz kullanımına geçmiştir. UNIX dünyası da 80’li yılların sonlarına doğru yavaş yavaş grafik arayüzlerle tanışmıştır. UNIX/Linux sistemleri ağırlıklı olarak server sistemlerinde yaygın olarak  kullanılmaktadır. Server sistemlerinde de grafik arayüz genellikle -yavaşlatıcı bir etken oluşturduğu için- bulundurulmamaktadır. Ancak kişisel bilgisayara yüklenmiş olan UNIX/Linux sistemleri ağırlıklı olarak grafik arayüzlerle kullanılmaktadır. Eskiden konsol ekranlarında karakterler ekrana kalıp olarak basılıyordu. Zaten bu devirlerde ekranın kontrolünü sağlayan elektronik birimler şimdikilere göre ilkel düzeydeydi. Sonra ekran nokta temelinde kontrol edilebilmeye başlandı. Bugün ekrandaki görüntüyü oluşturan en küçük noktasal birime pixel (picture element) denilmektedir. Modern grafik kontrol kartları bu pixel'leri işleyip ekrana gönderme konusunda çok yetenek kazanmışlardır.


  • Windows sistemlerinin çekirdek (kernel) ile entegre edilmiş bir grafik sistemi vardır. Bu grafik sistem geliştirici düzeyinde GDI denilen bir API kütüphanesi ile kullanılıyordu. Hala bu kullanım devam etmektedir. Sonra Microsoft yine GDI üzerine GDI+ isimli bir kütüphane daha tasarlamıştır. .NET Form uygulamaları bu kütüphaneyi kullanmaktadır. Fakat Microsoft zaman içerisinde GDI’nin yavaş olduğunu gördüğü için pek çok katmandan geçmeden grafik işlemlerini daha çabuk yapan ve ismine “Direct X” denilen bir kütüphane daha geliştirmiştir. Direct X önceleri yalnızca oyun ve animasyon programcıları tarafından kullanılıyordu. Daha sonra Direct X'i kullanarak GUI elemanları oluşturan kütüphaneler GUI kütüphaneleri de ortaya çıkmıştır. Bununların en bilineni .NET dünyasında kullanılan WPF (Windows Presentation Foundation) ortamıdır.
  • UNIX/Linux sistemlerinde grafik çalışma çekirdek ile entegre edilmemiştir. Örneğin Linux çekirdeğinde grafik çalışmayla ilgili hiçbir kod yoktur. UNIX/Linux sistemlerinde temel grafik işlemler ayrı bir katman tarafından yapılmaktadır. Bu katmana X11 ya da yaygın ismiyle “X Window” denilmektedir. X Window sistemi client-server mantığıyla çalışan aşağı seviyeli bir katmandır. X Window çok temel pencere ve grafik işlemlerini yapmak için düşünülmüştür. Bu nedenle modern GUI uygulamaları için yetersizdir.  X Window sistemini doğrudan kullanabilmek için XLib denilen kütüphaneden faydalanılmaktadır. XLib’in daha modern XRC isimli bir versiyonu da vardır. Tıpkı Microsoft'un Direct-X alt kütüphanesi gibi UNIX/Linux dünyasında da daha hızlı grafik işlemler yapmak için "Open GL" denilen bir kütüphane de geliştirilmiştir. Open GL belli bir zamandan sonra "cross platform" olmuştur. Bu kütüphane Windows sistemlerinde de kullanılabilmektedir. Bazı "cross platform" GUI kütüphaneleri arka planda Open GL'den faydalanmaktadır.
  • Machintosh sistemleri 10 versiyonuyla birlikte UNIX türevi bir çekirdeğe geçmiştir. Mac OS X’in kernel kodları açıktır ve buna Darwin denilmektedir. (Darwin geniş ölçüde Free BSD ve Mach çekirdeğinin kodlarını bulunduruyor.) Mac OS X sistemlerinde grafik işlemler Cocoa denilen bir kütüphaneyle yürütülmektedir. Bu kütüphane Objective-C ve Swift dillerinden doğrudan kullanılabilmektedir. Cocoa'nın C’den kullanımı için Carbon isminde bir API grubu bulunmaktadır. Özetle bugünkü Mac sistemlerinde grafik işlemler çekirdeğin üzerine kurulmuş olan ve ismine "Cocoa" denilen bir katman kullanılarak yapılmaktadır.

GUI dünyasında cross platform kavramı ise "birden fazla işletim sisteminde aynı biçimde kullanılabilirliğini" ifade etmektedir. Örneğin Qt framework'ü Linux, BSD gibi UNIX türevi sistemlerde, Windows sistemlerinde ve Mac OS X sistemlerinde aynı biçimde kullanılan bir ortamdır. Ancak Qt yalnızca kaynak kod temelinde bir taşınabilirliğe sahiptir, çalıştırılabilen (executable) kod düzeyinde bir taşınabilirliğe sahip değildir. Yani biz bir platformda oluşturduğumuz çalıştırılabilir (executable) bir Qt dosyasını başka bir platforma götürerek çalıştıramayız. Fakat biz bir Qt projesini başka bir platforma götürüp orada derlersek uygulama aynı işlevsellikle çalışacaktır. Bu da geliştiricilerin her platform için başka bir ortam ya da kütüphane kullanma zorunluluğunu ortadan kaldırmaktadır. Qt "cross platform" luk özelliğini her sistemde o sisteme özgü altyapıyı kullanarak sağlamaktadır. Örneğin  UNIX/Linux sistemlerinde Qt doğrudan X Windows sistemini kullanarak işlevselliğini sağlamaktadır.


Mac OS X sistemlerinde ise Qt Cocoa alt yapısını kullanarak yazılmıştır.



Qt’nin Windows sürümünde ise “Direct X” alt yapısını kullanmaktadır.


Özetle işletim sistemlerinin GUI altyapısı bu şekildedir.


Ve Cross platform uygulama geliştirecek olanlar bu altyapıları kullanarak geliştirmelerini yapmak zorunda ya da bu amaca uygun geliştirilen framework'leri kullanması gerekmektedir.

Library, Toolkit ve Framework Kavramları

5:06 AM

Dilimizde de ingilizce'deki karşılıkları kullanılan "library", "toolkit" ve "framework" terimleri birbirlerine benzer kavramları belirtmektedir. “Library” yani kütüphane içerisinde derlenmiş kodların (hazır fonksiyonların) bulunduğu dosyalardır. Biz "library" içerisindeki fonksiyonları, sınıfları istediğimiz yerde kullanabiliriz. "Toolkit" terimi çoğu kez belli bir amaca yönelik "library" topluluğu olarak kullanılmaktadır. "Framework" kavramının pek çoklarına göre ayırıcı özelliği akış kontrolünün terslenmiş olması (inversion of control)  durumudur. Yani "framework"lerde yalnızca akış bizde değildir. Framework içerisindeki kodlar akış kontrolünü ele alır bazı olaylarda bizim kodlarımızı çağırırlar. Aşağıdaki resimde gösterildiği gibi bir manzara daha açıklayıcı olacaktır. Ayrıca "framework"ler pek çok yardımcı araca da sahip olabilmektedir.


Genel olarak "framework" kavramı daha büyük ve geniş kapsamlı bir organizasyon belirtmektedir. Bu üç kavramın herkes tarafından kabul edilen kesin sınırları çizilmiş tanımlarının olmadığını söyleyelim.



Örneğin Qt için "library" "toolkit" ve "framework" terimlerinin hepsi bir dönem kullanılmıştır. Bugün itibarıyla Qt’ye “framework” demek daha uygun gözükmektedir. Bir sistemin basitce framework olarak tanımlanabilmesi için şu özelliklerin bulunması gerekir:
  • Karmaşıklığın kullanıcıya daha basit biçimlerde gösterilmesi
  • Bazı gereksiz (hammaliye) işlemlerin kullanıcının üzerinden alınması
  • Kod akışının ele geçirilmesi ve duruma göre programcıya belli zamanlarda verilmesi
Halbuki kütüphanlerde bir akış ele geçirmek ve arka planda birtakım işlemleri bizim için yapmak gibi bir amaç yoktur. Programın akışı bizdedir. Biz istersek kütüphane fonksiyonlarını çağırırız. Onlar da faydalı işlemler yaparlar. Şüphesiz pek çok framework aynı zamanda birtakım kütüphanelere de (API'ler) sahiptir. Bazı ara durumlarda o şeyin framework mü yoksa kütüphane mi olarak adlandırılacağı konusunda tereddütler olabilir.

Sistem Programlama Nedir?

5:49 AM
Sistem programlama temel olarak, geliştiricilerin sistemle daha alt seviye bir katman üzerinden iletişim kurduğu dolayısıyla geliştirmelerin sisteme daha yakın bir noktada yapıldığı yazılım geliştirme modeline karşılık gelir. Sistem programları geliştirilirken kullanılan diller aşağı seviyeli olma eğilimindedir. Bunları yazmak için belli miktar teori ve mühendislik bilgisi gereklidir. Sistem programlama, yazılımın ağır sanayisi niteliğindedir. Bu nedenle ülkemizde bu alanda çalışan ve kendini geliştirmeye çalışan insan bulmak biraz sıkıntılı olmaktadır.



Tipik sistem programları şunlardır:

  •  İşletim Sistemleri
  •  Derleyiciler ve yorumlayıcılar
  •  Editörler
  •  Debug Programları
  •  Virüs ve Antivirüs yazılımları
  •  Haberleşme programları
  •  Gömülü sistem programları
  •  Aygıtların programlanması, aygıt sürücüler
  •  Veritabanı motorları
  •  Sanallaştırma yazılımları
  •  Oyun motorları
  •  ...

Sistem programlamadan günümüzde pratik olarak, yüksek seviyeli dillerde uygulama geliştirmek yerine (C#,Java, Ruby vb.) daha alt seviye diller yoluyla gerçekleştirilir. Sistem programlama faaliyetleri için en çok kullanılan diller C, C++ ve Sembolik Makine (spesifik ve performans gerektiren konular için makine dili gerekebilmektedir) dilleridir. İşletim sistemi çekirdeği ile standart C kütüphanesindeki fonksiyonlar ve sistem çağrıları yoluyla iletişim kurulmasını gerektirir. Sistem programlamanın daha alt seviyeli dillerde yapılıyor olması, bu konuda kazanılan deneyimlerin yüksek seviyeli dillerde işe yaramayacağı anlamına gelmez. Aksine alt seviyeyi bilmek pekiştirici bir etki yaratır. Bununla birlikte yüksek seviyeli bir dille çalışırken sistem programlama kısımları bizim için çoğunlukla görünmez veya zor görünür olur. Bu nedenle uğraştığımız alanlar veya karşılaşacağımız kavramlar üst seviye dillerde çalışanlar için çok anlam ifade etmeyecektir. Kısacası programlamanın ayrı bir dünyasına giriş yapıyoruz. Yarı yolda kalmamak dileğiyle hepimizi kolay gelsin.


write(0, "Hello, world!\n", 15);

ne kervan kaldı, ne at, hepsi silinip gitti
iyi insanlar iyi atlara binip gitti.

Yukarıda bahsi geçen, kıymetı pek bilinmeyen o güzel insanlardan arta kalan Anadolu'da, çöküşe doğru gidişin durdurulamadığı şu zamanlarda, bize düşen de bu değeri bilinmemiş insanları hatırlamak ve umudumuzu kaybetmemek olacaktır.

Tenekeci Mahmut Güzelgöz

Tanburi Cemil Bey

Urfa'dan Üç Musiki Ustası

Zaralı Halil Söyler


Maçkalı Hasan Tunç





Çekiç Ali

Benim de vefatından çok sonra nasıl kıymetli bir değere Televole kültürüyle yaklaştığımızı anladığım bizim için Ciguli resmi adıyla Angel Jordanov Kapsov.


Koskoca akordeon üstadını sadece Binnaz ile bilmek ayrı bir vasıfsızlık olsa gerek.



Son olarak Linux ve Windows üzerinde sistem programayla ilgili paylaşımlarımı buradan yapacağım.