Bu yazıyı okumaya niyet ettiyseniz, ya vaktiniz çok yada merakınız. Burada sizlere Assembly dilini öğrenmenin gerekliliği hakkında nutuklar atmayacağım. Ama şunu söyleyebilirim ki; eğer gerçek bir sistem uzmanı olmak istiyorsanız assembly , isteseniz de istemeseniz de öğrenmeniz gereken bir dil olacaktır.
Çünkü assembly öğrenmek demek,

· Çalıştığınız mimariyi çok iyi tanımak
· Hatasız kodlar üretebilmek
· Yazılım eksikliklerini keşfedebilmek
· Hızlı ve eksiksiz programlama süreçleri oluşturabilmek

gibi size yetenekler kazandıracaktır. Assembly’de en azından orta seviye bir programcı olabilmek için; hardware yapıları,işlemci mimarisi,hafıza yönetimi, os mimarisi, process davranışları ve eğer ilgilenecekseniz network alt yapısının,katmanlarının ve iletişim mimarisinin nasıl çalıştığı hakkında bilgilere sahip olmak zorundasınızdır.

Ben şöyle düşünüyorum. Madem ki derlenen kodlar dönüp dolaşıp makine kodu’na dönüyor, öyle ise önce onu öğrenmeliyim ki sonra üst katman dilleri denen dillere geçtiğimde daha hatasız kodlar derleyeyim. E tabi bide karşılacağım opcode seviyesi hataların da yorum katabilip hata tespiti yapabileyim. E tabi bide işin hin oğlu hinlik tarafı var ama oradan bahsetmeyeyim şimdi.

Dokümana başlamadan önce şunu da belirtmek isterim ki, bu dokümanın hedef kitlesi herhangi bir programlama dilinde en azından orta seviyede bilgili ancak kendini sistem programcılığı konusunda da yetiştirmek isteyen arkadaşlar olacaktır. Dokümanı elimden geldiğince basitleştirip, arada bir iğrenç esprilerimden sıkıştırıp eğlenceli hale getirmeye çalışacağım.

Kısa bir giriş İşlemci

Burada işlemcinin ne olduğunu ve hayat hikayesini anlatacak değilim . Sadece bizi alakadar eden yerlerini bilmemiz yeter.

Nasıl ki diğer programlama dillerinde değişkenler kullanarak bazı değerleri onların içlerinde saklayıp işlemler yapıyorsak assembly içinde işlemcide bulunan registerlar o anlamı ifade eder. Register kavramı eskiden üretici firmalar arasında farklılıklar gösterse de günümüzde bu protokol artık oturmuştur.

Registerlar ile değişkenler arasında bir benzetme yapacak olursak.

Delphi için:



ise

assembly de bu



Bu registerlardan işlemcide genel amaçlı dediklerinden 8 adet bulunur. Bunlar:

EAX,EBX,ECX ve EDX tir. Bunlar 32 bit lik bilgileri saklarlar ve kendi içlerinde voltran oluşturduklarından ayrıcada bölünebilirler. Şöyleki

*EAX -> AX -> AH,AL
32b 16b 8b, 8b

*E demek Extended demek ilk işlemcilerde bu yoktu ve 16 bittiler registerlar
bu örnek yukarıdaki dörtlü için aynıdır. EBX -> BX -> BH,BL gibi

Şu ana kadar yazılanlardan bir şey anlamıyorsanız baştan okuyun veya google da daha basit olan ingilizce dökümanları bulun fakat bu anlatılanlar sizi zaten bildiğiniz şeyleri tekrar okutturup sıkıyorsa bir sonraki serileri doğrudan ilerleyen konulardan devam etmeniz daha iyi olacaktır.

Bu yukarıdaki dört register cpu tarafından kunta kinte şeklinde yönetilirler ve her şey için kullanılabilir. Bazı işletim sistemleri bu register’ları kendi isteklerine göre gruplandırmıştır. Örneğin Microsoft kendi API sistemin de işletilen fonksiyon geri dönüşlerini sürekli eax’a gönderir. Birde bunların haricinde EDI ve ESI vardır Intel bunları programcılara bir nevi kıyak olsun programcılar uğraşmasınlar diziler ile, koysunlar kopyalanması istenilen diziyi ESI'ye versinler hedef olarak EDI'yi atsınlar bi dongu komutu hepsi EDI'de Yani bi nevi kopyala yapıştır için iyi bir halta yarar bu iki kardeş register . İlerleyen zamanlarda movs, cmps gibi yardımcı komutlarından çıkması ile işlevsellikleri kanıtlanmıştır index registerlarının.

Unutmadan birde ESP var. Amacı ve işleme mantığı şöyledir Esp'yi bir bidon olarak düşünürsek hatta turşu bidonu olarak düşününki olay daha da basitleşsin. Turşu bidonumuza zerzevatı ben şu şekilde yerleştirirsem

| domates |
| kavun |
| hıyar |
| zerdali |
| floppy |
________/

bunları alırken hangi sırayla alırım . Intel işlemcileri bunu FILO işlemiyle alır yani First In Last Out - Türkçesi: İlk giren Son çıkar dileyen LIFO yani Last In,First Out’da diğebilir aynı şey J. Kısaca bu istiften yada Intel’in deyimi ile stack’ten ilk çıkan domates olur. Onun peşinden kavun ve en son floppy olur. Halbuki domates en son yığına giren nesnemizdi dimi ama? ESP genelde iki asm komutuyla yönetilir bunlar Push ve Pop tur. Örnekten devam edecek olursak Push komutu kovaya(stack) bi yeşillik atar ve kovanın içindekilerin in sayısını ve yerini tutan bir kayıttaki değeri(ESP) küçültür Pop ise tam tersini yapar kovadan en son atılan malzemeyi alır. Intel işlemcilerinde stackten veri alıp veri koyma işlemleri yaparken register değeri ya 4byte(32bit) artar yada 4byte azalır.


örnek
push 20 ; Stacke(kovaya) bi 20'lik attık
push 10 ; Peşinden onunda üstüne bi 10'luk
pop ax ; pop komutunu vererek stackin en üstündeki veriyi ax'e aldık ax=10
pop bx ; bx artık 20
add ax,bx ;ax=30

kolaymış değilmi?

Tabi bu stackten veriyi illaki en üstündeki alacağız diye bir kaide yok, dilersek stackteki en alttaki veriyi bile elde edebiliriz ama bunu yapan kodlar konumunuz hasebiyle şimdilik size uygun değil.

Şimdi sırada EIP registeri var
Bu yazmaç yazdığınız programların kodlarını bir sıraya sokar ve adım adım işler. Basit bir benzetme olması açısından Qbasic'i bilenler varsa hatırlarlar:

1 CLS
2 print "muck muck"
goto 2

deyip her komutu etiketliyorduk ya işte onun daha gelişmişi eip'tir. Bu register'a dışarıdan komutlarla müdahale şansı doğrudan yoktur. Onu derleyici bir kere ayarlar işletim sistemi de işlemciye yollar işlemcide bu sıraya göre teker teker gider. Ollydbg adlı debugger’ı kullanarak EIP yazmacının mantığını anlamanız daha kolay.

Segmentler:
CS: SS: DD: ES: FS: GS


CS DS ve SS : Programınızı yazıp derlediğiniz zaman, programınız sizin onu kodladığınız halinden milyon kez değişik bir halde çalıştırılabilir dosya haline gelir. Yani sizin anladığınız programlama yapısı ile işlemcinin anladığı yapı çok farklıdır. Siz kodunuzun kodlarının nerede,tanımlamaların nerede,sabitlerin nerede olduğunu bilirsiniz. Ama işlemci bunu ancak programınızı derleyen derleyicinin programınızın çalıştırılabilir kod haline getirdiği zaman içerisine eklediği bazı ipuçlarından faydalanarak bulabilir. İşte programınızın kodlarının nerede mahfuz tutulduğunu işaret eden olaya Code Segment(CS), verilerinizi işaret eden bölüme Data Segment(DS), değişkenleriniz,fonksiyon geri dönüşleriniz ve işlemci taraflı kod dallanmaları gibi göstergeyede Stack Segment(SS) denir. İşlemci programınızı çalıştırmak için hazırlık yaparken CS segmentine bakarak kodların yerini DS segmentine bakarak tanımlamaların yerini SS'ye bakar ise Stack'in yerinin bulur.

Peki işlemci kodların yerini buldu diyelim ancak bu kadar kodun içerisinden nereden başlayacağını nasıl bilecek. Yukarıda yazmıştık değil mi? EIP yazmacından. Siz programınızı derlediğinizde programlama dilinize ait compileriniz bu işlemi sizin için ve cpu için yapar. Programlama dili konseptlerin de şu vardır ki her yazılan kod için bir Entry Point vardır. Siz programınızı derler ve çalıştırırsınız ancak compiler önce sizin yazdığınız kodu icra etmek yerine, yazdığınız program için çalışacak ortamı hazırlamak için öncü bazı hazırlıklar yapacaktır. Her program için işletim sistemi o programa ait giriş noktasını gösteren CS:EIP çiftini hazırlar. İşlemci’de o CS:EIP ikilisine ait ,bazı çevrimler yaparak kodu icra etmeye başlar.

Şimdi hızlı bir giriş yaparak assembly programlamaya başlayabiliriz.

www.masm32.com Bu yazdığımız programları işe yarar hale getirmek için gerekli. Çektiğiniz zaman zipi sürücülerinizi kök dizinlerine açın ör: C: D: E: Ğ:

OllyDbg Buda derlediğimiz programlarımızı irdeleyebilmemiz için gerekecek.

Evet gerekenler bunlar ve hepsi içerisindeki örneklerden oluşan kabarıklığı saymazsak 1.5 mb kadar alan kaplıyor .

Masm32 Win ortamlarda assembly kodları ile çalışmak için geliştirilmiş bir derleyicidir. Yazdığınız *.asm uzantılı kodlarınızı size *.exe *.dll olarak sunar. Kabul ettiği ve anladığı tek şey assembly komutlarıdır.

Basit bir giriş yaparak aşağıdaki gibi bir örnek verecek olursak:



Evet yapısı itibari ile biraz karışık olduğu konusunda haklısınız ancak bu kanınızın ileride değişeceğine eminim. Şimdi yukarıda ki kod örneğimiz üzerinde ayrıntılı bir inceleme yapalım.



Bu komut masm32 derleyecisine(compiler)’e kısaca şöyle der: "Dostum bu programı yazan herifin yazdığı kodlar eski 386 işlemcilerin anladığı opcode'lardan oluşuyor derleme yaparken ona göre yap" der.Ancak bu seçeneği seçerseniz yeni nesil .686 işlemciler için çıkmış son nesil kodlardan yararlanamazsınız. Bu seçeneği isterseniz .686 da yapar yeni nesil komutlarla çalışabilirsiniz. Ayrıca bir diğer önemli hususta adresleme modlarıdır. Yani bu komut eğer .386 altı bir değer ise ör: .286 ve daha aşağısı gibi adresleme modları daha yeni nesil adresleme modlarını örmeğin(80386 Scaled Indexed Addressing Modes) [çok iyi bir indeks bulma yöntemidir zatî alîler-i]desteklemez. O yüzden en iyisi siz .386 ve yukarısını işlemci aileleri ile çalışmayı seçin sonra kafanız ağrımasın.



Bu komut ise programınızı kodlarken bir hafıza işlemi yaptığınızda ve yahut bir komut çağırdığınızda işe yarar. Şöyle ki: Eğer 32.bit için program yazıyorsanız genelde flat hafıza yöntemi kullanırsınız çünkü flat komutu hafızayı 4GB sanal bellek olarak varsayar.

Ne demek 4Gb sanal bellek kullanmak? Eski işlemcilerle hafıza sadece 640kb olarak adreslenebiliyordu,sonraları bu sınır segmentasyonda yapılan bazı değişikliklerle 1MB sınırına ulaştı. Ancak işlemci teknoloji gelişmiş ve 32’bitlik bir mimari kazanmıştı. Buda artık hafızaya 32 bitlik erişimler yapılabileceği anlamına geliyordu. Kısaca 32Bit erişimlerle 4GB hafıza adreslenebiliyor. (Bunu windowsunuzun hesap makinesinde 32 adet 1’lik biti yan yana getirip daha sonra decimale çevirdiğinizde görebilirsiniz. ) Peki sisteminizde 32 Mb Ram 512mb hdd varken(küçümsemeyin benim hala böyle çalışan bir sistemim var J) nasıl oluyor da her program 4GB hafıza kullanabiliyor. Bu aslında işlemci üreticilerinin geliştirdiği basit ama bir o kadar da harikulade bir numara. Olay şöyle cereyan ediyor. Her program için işletim sisteminiz sadece programınızı ilgilendiren bir tablo tutar. Bu tabloda programınıza ait hafıza adreslerini gösteren adına linear address dediğimiz konumlandırıcılar için fiziksel hafızada nereye denk geldiklerini gösteren girdiler vardır. Daha da basitleştirirsek: olayı 2 sütunlu excel tablosu gibi düşünebiliriz. A sütunu Doğrusal adresleri(linear) b sutunu ise Fiziksel adresleri belirtiyor olsun. Fiziksel adresten kastımız Ram’imizdir. Bu sütunlarda programınıza ait bazı en çok kullanılan doğrusal adreslere denk düşen fiziksel sayfa numaraları bulunur. Tabi o sütunların hepsinde her doğrusal adrese bir fiziksel adres denk geliyor diye bir kaide yok. Dedik ya sadece çok sık kullanılanlar o tabloda yer alıyor. Eğer işlemci programınızdan o tablonun fiziksel sütununda bulunmayan bir doğrusal adresini çağırırsa, işletim sistemi cpu için hdd’ye giderek o programın o doğrusal adresine denk düşen veriyi alır ve o fiziksel sayfa sütununa koyar. İşlemci de “her şey ne kadar güzel 1.76 gb’da bile verilere erişebiliyorum “ der J. Biraz daha anlatmaya devam edersem Hafıza modelleme konusuna geçiş yapmak zorunda kalacağım en iyisi burada kesmek.

Şimdi stdcall'e geçelim. Bu komut compilere(compiler masm32 de ml.exe’dir) prosedür çağrılarının stack’e hangi sırayla atılacağını ve alınacağını belirtir. Üç çeşitli vardır :

1-C 2-Pascal 3'te - Stdcall

Biz hep StdCall'i kullanırız . Niyemi?
Ne demiştik her programlama dili eninde sonunda kodlarını assembly’de anlaşılacak bir hale getirecektir. Ama bu çevrim işleminde bazı yerler vardır ki o programlama dilini yazan firmanın tercihidir karışamayız. Mesela C çağrım şartı için:

goster(int par1,int par2, int par3) gibi bir prosedür çağrısında işlemci bunu

push [par3]
push [par2]
push [par1]
call goster
add sp,12

şeklinde işleyecektir.

Yukarıdaki kod stacke par3'ten başlayarak değerleri koyar ve goster prosedürünün altındaki komutları icra edip kaldığı yere geri döner ve add sp,12 ise stack'i eski haline geri döndürür. Yani stacki eski haline döndürme işlemi prosedürün işi bittikten sonra yapılır .Ama Pascal çağrım şartında bu tam tersidir. Şöyleki:

topla:= par1+par2+par3 için bu asm'de
push par1
push par2
push par3
call topla

dır.

Add sp,12'nerde? Tabiiki Topla prosedürünün içerisinde . Yani stacki derleyip toparlama işi çağrım yapılan fonksiyonun görevidir.

Son olarak STDCALL ise bunların ikisinin karışımıdır. Yine örnekle açıklarsak

topla(int par1,int par2,int par3) prosedürü asm'de

push [par3]
push [par2]
push [par1]
call topla

dır.

C çağrım şartı, fonksiyon veya prosedürle verilen operatörlerin en sağından başlayarak stacke koyma işlemini yapar ve fonksiyondan sonra stacki düzenler.Ama Pascal bunun tam tersini yapar ve stacke koyma işlemini soldan sağa yapar ve stacki fonksiyonun içinden çıkmadan düzenler.Stdcall ise C gibi stacke alma işlemini sağdan başlar ama pascal gibide fonksiyon içerisinde stacki düzenler.

Bu anlatılanları bir debuger’la sınarsanız mantığı daha iyi kavrayacağınıza eminim.

Evet bu kısmıda anladıysak devam ediyoruz..

Bu yönerge programcının isteğine bağlıdır. Şöyleki Bununla compilere dersinizki: "Yazdığım tüm komutlar ve ne kadar şey varsa bunları küçük büyük harf ayrımına tutma. Ben acaip bi insanımdır bazen "push" yazarım bazende "PuSh" sen benim keyfime karışma" der. Bunuda anladıysak kaynak kodumuzdan bir satır daha aşağıya iniyoruz.



Yukarıdaki komutlar compilere (derleyiciye) bizim hangi yardımcı komutlarla çalışacağımızı söyler. Bu .inc dosyalarının içerisinde bazen komut makroları bazende işletim sistemi fonksiyonlarının komutun kaç paramtre ve hangi tipte boyda veri alacağını belirten tanımlamalar yer alır. İlgili dizindeki dosyaları açarak ne demek istediğimi daha iyi anlayacağınıza inanıyorum.



includelib komutuda compilere çalıştığımız yardımcı komut kütüphanelerinin hafızadan veya dosyadan çağrılacak offset tanımlamalarını belirtir.



Evet EXE'ler nasıl çalışır adlı dokümanımı okumayanlar için bir daha tekrarlayayım . Her çalıştırılabilir dosya ki buna .dll'lerde dahildir, içlerinde programcı tarafından önceden tanımlanmış bilgiler ".data" veya kullanıcıdan veyahut etkileşimli bir komuttan alacağı verileri muhafaza için ".data?" ve program içinden dahi değiştirilemeyecek readonly, gerekli ön tanımlama bilgileri ".const" ve tüm yazılımsal kodları içeren ".code" gibi alanlara sahiptir.

Özetle

.DATA Kullanıcıya iletilecek önceden tanımlanmış veriler veya program içerisinde kullanılacak bazı ön tanımlı değerleri tutar. Buna örnek olarak kaynak kodumuzda belirttiğimiz



gibi bir tanımlama verilebilir.

.DATA? ise hafızada yeri ve mekanı belli ama içerisinde hiç bir bilgi olmayan , dışarıdan gelecek her veriye "gel ne olursan ol yine gel" diyen bir alandır Örneğin



Yukarıdaki gibi bir kodda programı ilk çalıştırdığınızda buffer alanı hafızada ayrılmış ancak hiç bir bilgi içermeyecektir. Ta ki yukarıdaki “mov” komutu icra edilene kadar.

.CONST Komutu ise program icra edilirken, ne kendi içerisinde ki bir müdahaleyle ne de dışarıdan alınacak bir girişimle değiştirilemez verileri tanımlar. Mesela bir web server yazdık bunun portunun değiştirilmez bir şekilde 80 olmasını istedik. Bunu :


diyerek yapabiliriz.

Her programlama dilinde olduğu gibi assembly’de de data tanımlama belirteçleri vardır. Bunlar:
db = Define Byte (8Bit)
dw = Define Word (16Bit)
dd = Define Dword(32Bit)
..
dup(?) = Define memory up (miktar)

Yukarıdaki tanımlamalar hafızada belirtilen değerlerde veri girişi sağlar.

Elinize bir kalem kağıt alın yada paint'i açın. Büyük bi dikdörtgen çizin . Bu çizdiğiniz şey sizin programınızın kullanacağı hafıza alanı . Evet windows sizin programınızı böyle bir şey gibi görür. Sizin yapmanız gereken az önce bazılarını yukarıda da anlattığım .data .data? .const .code gibi sınır çizgileri ile bunları bölmek. Yani programınız hafızada artık en basitinden ".data .code ve .stack" gibi görünecektir.

Evet artık size düşen bu alanlarla oynamak. Yukarıdaki kodumuzu inceleyin o hem .data section için hafızada ayrılan boşluğa veri yazar, hemde .code içinde belirtilen kodlar için hafızada kod bloğu oluşturur. Bu data yazma işlemini örneğin

mesaj db "Selam millet",0
veya
sayi dd 0125468984h
veya
handle dw 015fah

gibi yazarız . Bunlar ne anlama gelir.

Eğer hafızaya bir string girecekseniz bunu db ile yapmalısınız. Niyemi? hatırlayın her ascii harfinin tekinin boyutu nedir? 1Byte!. Öyle ise ben :

mesaj db "Selam",0

dediğimde bu hafızaya byte byte yazılacaktır . Şöyleki:
Hafıza:

00403000 53 65 6C 61 6D 00 00 00 00 00 00 00 00 00 00 00 Selam

gibi olacaktır.

Ama bunu gidip
mesaj dd "Selam" deseydim hafıza:

00403000 53 00 00 00 65 00 00 00 6c 00 00 00 00 61 00 00 S...T...R

gibi birşey olacaktı ve programınızın ekrana S yazıp bitecekti. Çünki windows stringler için 00'ı terminated data(sonlandırıcı) olarak tanır.

Evet artık .code .stack. data .const compile, verilerin hafızada nasıl yerleştiği, çalışan processin bir debuggerda nasıl gözüktüğü,sectionlar anlamış olmalısınız ve evet artık sizinle güzel örneklere başlayabiliriz.

Burada şöyle bir yöntem kullanacağım . Sizinle birlikte daha kolay anlayasınız diye masm32'nin içinde yer alan icztutes klasörünün içindeki Iczelion’un yazdığı örnekler üzerinde çalışacağız .

Şimdi ilk önceliğimiz size göre tute02 almalıydı ama o zaten yukarıda verdiğim örneklerle birebir aynı ben onu geçip doğrudan TUTE03 klasöründe yer alan WIN.asm uygulamasının üzerinde çalışmayı yeğliyorum.



Win.asm'nin içeriği aşağıdaki gibidir.



Program çok basit bir windows penceresidir. içinde hiç bir şey yoktur ve kapat komutundan başka hiç bir komuttan anlamaz.


Windows'ta işler çoğunlukla pencerelerle yürür. Örneğin siz şu anda bu sayfayı Windows işletim sistemi yardımıyla görüntülüyorsanız bu Pencerelerin sayesinde oluyor. Yani şu anda bu okuduğunuz doküman bir pencerenin içinde yer alıyor ve bu pencere genel olarak "açma,kapama,ölçekleme,büyütme ve küçültme, üzerinde yapılan değişiklikleri algılama,fare hareketleri,klavye gönderimleri, başka pencerelerle veri akışı vs.. bir çok yapıyı idare eden bir yapıdadır. Penceremizi yöneten ve onunla çalışmamızı sağlayan GUI’dir, iş akışını idare eden ise Win32 Messaging sistemidir. Yani siz bu pencerenin üzerinde her mouse hareketi yaptığınızda win32 subsystem bu pencereyi kontrol eder ve mouse koordinatlarını yine bu pencereye mesaj olarak iletir ve eğer bu pencereyi yazan programcı bu hareketler için özel tepkiler programladıysa onları pencerenin icra etmesini sağlar. Yukarıdaki örnekteki kodda penceremiz sadece gelen kapat bildirimini almakta ve pencereyi yok etmektedir. Bundan başka gelen her komutu ise DefWindowProc prosedürüne ileterek isteğin Win32 tarafından denetlenmesini ister. GUI kütüphanesi ile pencerelerinizin tasarımını yönetirsiniz. İkonu, şekli, üzerinde yer alacak butonlar,resimler vs.. sizin için hazır olarak bulunan Api’ler ile bunları rahatlıkla yapmanız için GUI tarafından desteklenir.

Her pencere standart olarak bir çerçeveye o çerçeve üzerinde bir başlık çubuğuna, başlık çubuğu üzerinde opsiyonel olarak kapatma,ölçekleme ve simge durumuna alma tuşlarına sahiptir. Bu Windows'un pencere standartıdır. Ama biz gerçekte daha zengin pencerelerle karşılaşabiliyoruz. İşte buda pencerelerin opsiyonelleştirilebilmesi gerçeğini ortaya koyuyor. Evet pencereler aslında her özellikleri ile değiştirilebilecek nesnelerdir.

Windows'da pencere oluşturmak istersek yapmamız gereken bazı zorunlu haller vardır onlar her pencere için bir ana prosedür olan WinMain proceduru ve o pencereye gelecek mesajları irdeleyecek WndProc prosedürü. Bu ikili bir pencerede birlikte olmak zorundadırlar. Biri ki bu WinMain oluyor Pencere ve özelliklerini ayarlayıp pencereyi kullanıcıya sunar ve gelen her isteği dinler, diğer yani Wndproc ise bu gelen mesajlara göre programcının tepkisini yansıtır. Aslında pencere konusunu biraz daha açarsak, bir pencere oluşumu için gerekenler şunlardır.

1. Win32’nin programımıza bağlı pencere ile iletişime geçebilmesi için bir instance handle alınır. Bu handle vasıtası ile penceremizin ana fonksiyonuna ulaşırız.
2. Penceremiz için bir class name ve de bir class yapısının içini oluşturmalıyız. Bu class, penceremizin temeli niteliğindedir. Penceremiz için gereken görsel ve yapısal ayarların geneli burada yapılmalıdır. Örneğin: Penceremize gelen mesajları hangi prosedürün inceleyeceği, mouse imlecinin şekli,arkaplan rengi gibi çoğunu örnek kodumuzda da göreceğiniz ayarları bu sınıfta tanımlarız.
3. Oluşturduğumuz Class’ı Register etmeliyiz. Bu RegisterClassEx api’si ile yapılır. Böylece penceremizi oluşturduğumuzda ne tür bir yapı ile çalışacağını windows’a belirtmiş olacağız.
4. Penceremizi oluştururuz. CreateWindowEx api’si ile bunu yapabiliriz. Bu komut ile birlikte artı penceremiz hafızada yapısal olarak son şeklini almıştır.
5. Pencere görünür hale getirilir. Hafızada yapısal olarak bitmiş penceremizi ShowWindow komutu ile artık kullanıcılara sunarız.
6. Bir defaya mahsus Windowsun penceremiz için Refreshing işlemi yapmasını sağlarız. Bu sayede penceremiz artık gerçekten desktopumuzda aktif işlem olur.
7. Penceremiz için istekleri dinleriz. Evet artık penceremiz hazır ve aktif olduğuna göre penceremiz için kullanıcı bazlı veya diğer programlardan gelebilecek istekler için sonsuz bir dinleme haline girmeliyiz. Bunu GetMessage ve DispatchMessage api’leri vasıtası ile yaparız. GetMessage api’si penceremize uğrayan her mesajı Windows’un mesaj kuyruğundan alır ve DispatchMessage gönderir. DispatchMessage işe gelen isteği irdeler ve 2. adımda belirttiğimiz Pencere prosedürüne gönderir.
8. Ve penceremiz ile işimiz bittiğinde onu sonlandırırız.



Şimdi kodu inceleyelim.



Buraları anlatmıştım o yüzden es geçiyorum.



ClassName pencereler için çok önemlidir. Çünkü her pencere Windows iyi bir kategorilendirme yapabilsin diye ve de mesajlaşma sistemi kullanılabilsin için bu class name ve application name ihtiyaç duymaktadır . Hani bilirsiniz kendi uygulamanızdan başka bir uygulamaya mesajlar gönderirsiniz FindWindow ile bu iş, işte böyle yürür.



hInstance daha öncede bahsettiğim gibi Windows’un programımızın varlığını bilsin için ve kendi içinde haberleşmelerde kullanması hasebiyle kullanmak zorunda olduğumuz bir değer. Bu değer Win32 tarafından bize sağlanan 32 bitlik sayısal bir değerdir ve çoğunlukla win32 altında bu değer programımızın hafızadaki doğrusal adresidir.

CommandLine ise tamamen programcının isteğine bağlı tek amacı programınıza dışarıdan gelen komut parametrelerini almak olan bir api’dir. Örneğin programınızın adının spy.exe olduğunu düşünürsek, kullanıcı bu programa doğrudan çalıştırma yoluna gitmeyip parametre ekleyerek(ör:spy.exe –minimize) çalıştırırsa siz bu ilave parametreyi CommandLine sayesinde programınızın içerisinde değerlendirip tepki verebilirsiniz.



Evet sonunda bizi gerçekten ilgilendiren yere yani kodumuza girmiş bulunuyoruz. Şu unutulmamalıdır ki masm32 ile programla yaparken icra edilecek kodlarımız .code section’da iki ana etiket arasında bulunmalıdır . Bu programımızın iskeleti niteliğindedir. Ön tanımlı olarak masm32’de bu etiketler start: end start olarak tanımlanmıştır ve bu isimleri rahatlıkla dilediğiniz gibi değiştirebilirsiniz. GetModuleHandle komutumuz yukarıda da belirttiğim gibi bizim için windowstan bir başlık alır. Bu komutun icrasından geri dönen değer “eax” yazmacında dır.

Not: Windows kendi tanımlaması olarak fonksiyon dönüşlerini eax’ta alır .Bizde bu mimariye uymak zorundayız.

Eax’te ki değeri “mov” komutu ile ileride kullanabilmek için hInstance değişkenimize alıyoruz. Ardından GetCommandLine ile programımıza dışarıdan gelen isteklerin bulunduğu hafıza alanına ait değeri yine “eax” vasıtası ile alıp CommanLine değişkenimize gönderiyoruz. Dilersek daha sonra bu alandaki verileri değerlendirip özel işlemler yapabiliriz ancak bu örneğimizde böyle bir şey yok.

WinMain penceremizi oluşturmamız için giriş noktamızdır. WinMain ismi tamamen isteğe bağlıdır yine diğerlerinde olduğu gibi bunu da dilediğiniz gibi değiştirebilirsiniz. WinMain 4 parametre alır. Bunlar sırası ile
1. Win32’den aldığımız handle’mız,
2. Win16 günlerinden kalma ama artık kullanılmasının pek esprisi olmadığını düşündüğüm yedek handlemiz,
3. Komut satırı verilerini barındıran parametrelerimizin yerini gösteren pointerimiz.
4. Penceremizin başlangıçta hangi biçimde görüneceğini belirten CmdShow belirtecimiz.

ExitProcess ile de programımızı güvenle terk ederiz.




LOCAL komutu biz herhangi bir fonksiyonda yalnızca o fonksiyonun kullanması için değişkenler atadığımızda bizim için stackten hafıza ayırır. Bizi ilgilendiren yer ise penceremiz olduğundan daha öncede bahsettiğim pencere sınıfımız için yapılması gereken bazı tanımlamaların kullanması gereken bir yapının kurulması. Windows bu yapıyı WNDCLASSEX içinde görmek istediğinden onu ve ona point olan “wc” değişkenimizi yazdık. Ayrıca mesajlarımız için yine win32 ön tanımlı olarak MSG yapısı ve penceremizi için mesajlaşmalarda kullanacağımız 32 bitlik bir dword olan HWND’yi belirttik. Biz bunları local ile yaptığımızdan bu fonksiyonun dışında başka yerde kullanılmaları söz konusu değildir.



Yukarıdaki komut kümesi tamamı ile sık sık kendinden bahsettiğimiz pencere sınıfımızın içeriğini doldurmak ile ilgilidir. WNDCLASSEX gibi bir yapıyı doldurmamızın amacı ileride aynı şablonda birden fazla pencere oluşturacağımız anlarda bunu bir çok hafıza alanı tüketmektense varolan bir hafıza alanında onu point ederek üretmek olacaktır. Ayrıca yine belirtmeliyim ki WNDCLASSEX yapısı gibi Windows’ta hazır olarak ön tanımlı bir çok pencere sınıfı vardır. Örneğin editbox, button bu gibi sınıflardır ve sadece CreateWindowEx api’si ile herhangi bir yapının içini doldurma gereği olmadan oluşturulabilirler. Şimdi herşeyin neden object olduğunu anlamışsınızdır umarım J . WNDCLASSEX yalın halde aşağıdaki gibi bir yapıdır.



mov wc.cbSize,SIZEOF WNDCLASSEX ile kullanacağımız yapının boyutunu alırız. Bu bound ayarı ve windows’a register ederken doğru tanımlama yaptığımızı garantilemek açısından önemlidir.

mov wc.style, CS_HREDRAW or CS_VREDRAW, ise pencerelerimizin ölçeklendirme işlemlerinin her taraftan yapılabileceğini belirtir. Dilerseniz farklı bir çok seçenek daha eklenebilir. İlgili opsiyonlar Windows.inc dosyasında yer alırlar.

mov wc.lpfnWndProc, OFFSET WndProc penceremize uğrayacak her türlü mesajın işlenmek için hangi prosedüre yollanacağını belirtir.

mov wc.cbClsExtra,NULL işletim sistemi tarafından boş bırakılır . Extra sınıf tanımlamaları için sonradan kullanılması planlanan veriler buraya point edilir.

mov wc.cbWndExtra,NULL. Eğer class tanımlaması ayrı bir dosyada (*.rc) yapılmış bir dialog kutusu sınıfı ile çalışacaksanız bu alanı doldurmak zorundasınızdır.Tabi bizim ilgi alanımız şimdilik yalın pencereler olduğundan boş bırakıyoruz.

push hInstance
pop wc.hInstance ile programımıza ait handle’i pencere sınıfımıza atıyoruz.

mov wc.hbrBackground,COLOR_WINDOW+1 penceremizin arka plan renk seçimini yapıyoruz. Daha fazla renk seçeneği için include dosyaları incelenebilir.

mov wc.lpszMenuName,NULL Eğer pencerenizde tıpkı internet explorerda veya office programlarında olduğu gibi Dosya,Düzen,Görünüm,Yardım gibi ilave araçlar içeren bir menü çubuğu istiyorsanız ilgili yapının adresini de buraya belirtmelisiniz.

mov wc.lpszClassName,OFFSET ClassName. Bu pencere sınıfımızı register edebilmek ve ileride program içinden veya dışından penceremizin görsel ayarları ile oynamak istediğimizde kolayca ulaşabilmemizi sağlayan bir belirteçtir.

invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax ile penceremizin sol üst köşesinde veyahut ta minimize edilirken ki halinde gözükmesini istediğimiz icon’u belirtiriz.

invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax burada da tıpkı LoadIcon api’sinde olduğu gibi pencere içinde mouse’mizin almasını istediğimiz şeklini çizdirebiliriz.

invoke RegisterClassEx, addr wc ve artık istediğimiz ayarlamaları yaptıktan sonra bu komut ile penceremizi windows’a kayıt ettiriyoruz.

INVOKE CreateWindowEx,NULL,ADDR ClassName,ADDR AppName,
WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,
CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,NULL,
hInst,NULL

ve artık penceremizi servise sunma zamanı geldi. CreateWindowEx fonksiyonu 12 parametre içerir . Genel yapısı şöyledir.

CreateWindowExA proto dwExStyle:DWORD,
lpClassName:DWORD,
lpWindowName:DWORD,
dwStyle:DWORD,
X:DWORD,
Y:DWORD,
nWidth:DWORD,
nHeight:DWORD,
hWndParent:DWORD ,
hMenu:DWORD,
hInstance:DWORD,
lpParam:DWORD
.dwExStyle: Bu parametreyi biz boş geçtik ama dilerseniz siz pencerenizin sürekli ekranın üstünde görünmesi gibi özel ayarlamalar yapabilirsiniz.

.lpClassName: Bu mutlaka gerekli bir parametredir. Çünkü hangi pencere sınıfının gösterileceğini daha önceden kayıt ettirdiğiniz pencere sınıfı ismini alarak yapmaktadır.

.lpWindowName: Pencerenizin başlık çubuğunda yazmasını istediğiniz string ifadeyi alır. Eğer NULL geçerseniz başlık çubuğunuzda hiçbir şey yazmaz.

.dwStyle: Bu parametreyi doldurmazsak başlık çubuğunda ne kapama nede büyültme ve küçültme tuşları olmazdı. Biz ortak bir tanımlama olan WS_OVERLAPPEDWINDOW ile standart butonların olmasını istedik.

X,Y: Pencerenin sol üst köşesin bulunacağı koordinatı verir. Biz default değeri vererek bu işi windowsun gönlüne bıraktık

.nWidth,nHeight: Kısaca penceremizin eni ve boyu. Biz yine bu işi windowsa bıraktık.

.hWndparent: Eğer aynı özelliklerde ana pencerenize bağlı başka bir alt pencere oluşturmak isterseniz bu değeri ilgili child pencerenin handle ile doldurmalısınız. Bu bir nevi MDI tarzı bir görüntü oluştursa da child pencere hiçbir zaman ana pencerenin boyut sınırları arasında değildir. Yani istediğiniz yere masa üstünde sürükleyebilirsiniz. Ancak bu şekilde üretilen child pencereler ana pencere kapandı anda otomatik olarak kapanacaktır.

.hMenu: Eğer zaten WNDCLASSEX ile pencere sınıfınıza menü eklediyseniz bu parametreyi boş geçebilirsiniz. Menü kullanmak istemediğinizde de boş tur. Ancak menu kullandığınızı ve menu sisteminizi sayısal değerlere sahip id ler ile yönetmek istediğinizi varsayarsak o zaman bu parametre sizin için kullanışlı olabilir.

.hInstance:Bu da yine kalıtımsal olarak hiyerarşik bir şekilde programımızın başında windowstan elde ettiğimiz handle’dir.

.lParam: Kendi tasarladığınız veya ön tanımlı yapıların mesaj olarak pencerenize iletilmesinde kullanacağınız bir parametredir. Örneğin çok pencereli MDI formlarda CLIENTCREATESTRUCT yapısını pencerenize vererek daha sonra client lara GetWindowLong ve SetWindowLong api’leri vasıtası ile değişiklikler yapabilirsiniz.

Evet ayrıntılı bir şekilde de CreateWindowEx api’mizi inceledikten sonra devam ediyoruz.
CreateWindowEx apiside çalıştıktan sonra yine “eax” içinde hafıza oluşmuş penceremizi gösteren pointer’i dönderiyor. Artık penceremizin hafıza belli bir imajı çıktı ve bizim onu görücüye çıkartmamızı bekliyor. Bunu yapmanın yolu ShowWindow api’si. ShowWindow api’si iki paramtre alır bunlardan ilki hafıza yer alan ve bize ait olan pencerenin handle’ı, diğer ise pencerenin kullanıcıya sunum şeklini belirten CmdShow parametresi.

İnvoke ShowWindow,hwnd,CmdShow ; diyerek penceremizin kullanıcıya daha önceden WinMain içinde verdiğimiz CmdShow değişkeninde belirtilen niteliğe göre gösterilmesini sağlarız.

Artık penceremiz gözüküyor ancak bu kaba bir tabirle kuru bir yaprak sayfası gibidir. Bu pencereyi kullanıcıdan mesaj alıp verebilmesi için bir kere tetiklememiz lazım ve bunu

İnvoke UpdateWindow,hwnd; ile yapıyoruz.

Artık program emir almaya hazır ancak bu gelecek olan istekleri ne ile toplayacak ve ne ile işleyecek. İşte buraya sıradaki adamlarımız mesaj komutları devreye girer. Kısaca şöyledir.



Gördüğünüz gibi bu işlemi sonsuz bir döngüde yapmak zorundayız aksi halde dakikada binlerce mesaj akan bu win32 sisteminden bize ait olan mesajları almamız olanaksız olurdu.GetMessage api’si penceremize ait bir mesaj gelene kadar bekler. Yani kod akışı orada durur. Ta ki dışarıdan bir müdahale gelsin ve gereken prosesler başlasın.

İnvoke GetMessage,addr msg,NULL,0,0 Win32’nin mesaj kuyruğundan bir mesaj alır ve eğer mesaj bizim penceremize ait ise msg yapısının için doldurarak bir alt yordama havale eder. GetMessage geriye eğer WM_QUIT gibi bir çıkış mesajı alır ve False döndürürse bu döngüden çıkılması anlamına gelir.


.invoke TranslateMessage api’si aslında kullanılması zorunlu olmayan bir api’dir. Tek amacı pencerenize klavyeden gelen klavye vuruşlarını ascii kod olarak doğrudan işlemesidir. Dilerseniz kullanmayabilirsiniz.

İnvoke DispatchMessage ise mesajı alır ve Mesajları işlemekle yükümlü fonksiyona gönderir. Bizim örneğimizde bu WndProc’tur.



Mesaj döngüsünden çıkılıp program sonlandırılacağında msg yapısının wParam parametresinde çıkış kodu yer alır. Aslında windows bu değer bir daha kullanmaz ama oyunun kuralı gereği güvenli çıkış adına bunu şart koşmuştur. Keşke her işlerinde bu kadar sağlam olsalar J .

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Bu bizim pencere işleyicimiz. Bu yapının anlaşılması çok önemlidir. Fonksiyonun aldığı parametreler şunlardır.

HWND: Her fonksiyonda olduğu gibi buradada ilgili handle’mızı kullanıyoruz.

.umsg:UINT: Gördüğünüz gibi bu msg yapısı gibi bir şey değil sadece bir sayısal ifade. Windows’ta binlere mesaj vardır ancak programlarımız sadece kendilerini alakadar eden mesajlarla ilgilenirler. Bu UINT değeri sayesinde sadece istediğimiz ilgili mesajın sayısal ifadesine denk gelen mesajla ilgilenebileceğiz anlamına gelir. Örnekleri ileride görecekseniz.

WParam,LParam: Bazı mesajlarla birlikte bazı ilave bilgiler de gelir. Örneğin pencerenizde yer alan bir butona basıldığında bunun mouse ile mi yoksa klavye ile mi gelen bir mesaj olduğunu wParam ve lParam öğeleri ile birlikte gelen değerlerden anlarız.



Bu kısım en can alıcı noktayı içeriyor. Burayı iyi anlamınız şart. Ne demiştik! Her pencere devamlı mesajlarla meşgul olur. Bunu bir debugger’la daha iyi anlayabilirsiniz. Siz pencereleriniz üzerinde işlem yapıldığında gelen isteklere gerekli yanıtı verebilmek adına bir filitre belirlemelisiniz. Örneğin siz programınızı her ne kadar da sakin rahat rahat çalışıyo sansanız da, programınız kendisi ile alakalı veya alakasız binlerce mesaj bombardımanına tutulur. Üziernde fare ile gezerken,bir click atarken, bir yerde bir yere taşırken,klavye ile bazı tuşlara basarken, siz programınıza bu isteklere karşı cevap verecek bir modül yazmasanız dahi bu istekler ile programınız meşgul olur. Peki bu kadar mesaj nasıl oluyorda siz bir şey yapmadan işleniyor. Yani pencereyi sürüklüyorsunuz ve istediğiniz yere gidiyor ama bunu siz yazmamıştınız. İşte bunu DefWindowProc halleder. Bu api sizin programınızda belirttikleriniz dışında programınıza gelen mesajları windows’a yönlendirir ve onun muhatap olmasını sağlar sizde böylece sadece kendi belirlediğiniz mesajlar ile rahatça ilgilenebilirsiniz. Tıpkı .IF uMsg==WM_DESTROY da ki gibi. Biz bu komutla uMsg’ya gelen sayısal değeri WM_DESTROY mesajına denk düşen mesajları işleyeceğimizi belirttik ve eğer mesaj gelirse şu işlemi yap dedik.

Evet bu yazınında sonuna geldik. Yazım hataları ve anlam karmaşası olan yerler için özür dilerim. Bir daha ki bölümlerimizde kaldığımız örneklerden devam etmeye çalışacağız inşAllah.

Selametle.

Not: Döküman biraz karışık ve birbirinden kopuk ilerliyor farkındayım. Ancak üzülerek söylemeliyimki bu dökümanı bile iş aralarından fırsat bulup ilerletebiliyorum o yüzden inşAllah döküman bittiğinde baştan aşağı bir tarama yapıp gerekli düzenlemeyi yapıcam.

WIN32 API

Bu aşamaya gelene kadar hafıza da veriler nasıl ve hangi tanımlayıcılarla tanımlanır. Derlenmiş dosyanın hafızadaki şablonu nasıl bir hal alır. Stack nedir, section nedir, veriler hafızada nasıl dizilir,byte,word,dword tanımlamalar arasındaki fark ve bir çok kafa karıştıran konu artık bana göre kafanızdan silinmiş olmalı. Olmalı ki artık verilen örneklerden ve incelediğiniz kodlardan daha çok şey çıkarabilesiniz.

Bu yazıda anlatmak istediklerim yine konumuzla bağımlı ve öğrenme sürecinizi maximum seviyeye çıkarmaya yöneliktir. Örneğin bu yazımızda sizlere Win32 programlama yaparken API'lerin ne olduğu,nasıl çalışıldığı Win32 için olan önemleri ve kategorizasyonları. Kaç çeşit oldukları,kaç şekilde ulaşılabildikleri,hafızada ki konumlarının değişkenlik haritasının tanımı gibi kafanızı darman durman edecek bilgileri anlatmaya çabalayacağım. Ve artık bunları siz iyi kavradıktan sonra hangi dil ile olursa olsun win32 programlama yapmanız çok daha basit olacaktır. Ama tabi ben isterim ki programlama dili seçeneğiniz Masm32 olsun .

API'ler

Açılımı Application Programming Interface(Uygulama Programlama Arayüzü)’dir. Ama ben de bir tanım eklersem "Programcıların başka programcılara kıyak olsun "zaten ben bi tane yazmışım gariplerim uğraşmasın" diye ve üstelik kendi programlarının veya yapılarının da bütünlük garantisi olsun diye geliştirip export ettikleri bir fonksiyonlar destesi" diyebiliriz. Şöyleki siz kullandığınız işletim sisteminde olmayan bir disk onarım programı yazdınız ama dedinizki "yaw ben bunun görselliğini iyi yapamadım hem bu fonksiyonları yazana kadar göbeğim çatladı bi de kullanılabilirliği ile mi uğraşacaktım bir çok yeride eksik kaldı,banane canım: "ederim işlevsel fonksiyonları export uğraşsın başkası "" derseniz bu yaptığınız şeye api denir. Diğer programcılar sizin dll'nizi programına import eder ve o fonksiyonları kullanır ve sizinkinden daha janjanlı program yazar ise o programcı sizin api'leriniz ile bu işi yaptı demektir.Ve üstelik bu sayede de hem sizin geliştirdiğiniz teknoloji dehası kodlarınız bütünlüğü ve yapısallığı ile korunmuş olacak hem de sizin şablonunuz üzerinden kim bilir daha ne programlar geliştirilecek.

İşte Win32 Api'leride kendi yeteneklerini programcılara sunan geniş bir yelpazeyle yapar bu API işini. Aslında buna pek sunmak değilde dayatmak desek daha yerinde olur. Yani win32 açıkcası programcıların ince mevzularla kendi başlarına fazla haşır neşir olmasını istemez ve illa benim yeteneklerimi kullan der. Örneğin winnt serisinde yapısı gereği seri porta dahi doğrudan çıkış yapamazsınız .

API'ler yukarıda yapılarından da bahsettiğimiz gibi programcısının yazdığı ve export ettiği bir fonksiyonlar yumağıdır ve bu api'ler executable dosyalar içerisinde hizmet etmek için depolanırlar. Kernel32.dll,ntdll.dll,gdi32.dll,user32.dll ve bazı *.exe'lerin içlerinde hayatlarını idame ettirirler. Windows amca bu api'leri bazı kategorilere ayırmıştır. örneğin

Bir nesne veya dosya oluşturuken
Bir dosya ararken
Parametre yollar veya alırken
Sürücülerle çalışırken
Programlar arası veri transferi yaparken
Programdan girerken veya çıkarken
Hafıza ayırırken
Sistem mesajlarıyla boğuşurken
vb.. daha buna benzer veya daha farklı yaklaşık 949 ince tefferuatlı iş için KERNEL32.DLL

String çevrim işleri yaparken
Kullanıcı etkileşimli dialoglar görüntülerken
Klavye düzeni ve mouse hareketleriyle haşır neşir olurken
Cut+copy+paste işlemlerini yönetirken
Ekrana kalıp şekiller çizerken
Mesajların istenilen yerlere yönlendirmesini sağlarken
Başka programlara erişirken
ekrana yazı yazdırıken
vb.. daha buna benzer veya daha farklı yaklaşık 732 ince tefferuatlı iş için USER32.DLL

Fontlarla çalışırken
Ekrana cicili bicili şeyler çıkartırken
grafiklerle boğşurken
vb.. daha buna benzer veya daha farklı yaklaşık 609 ince tefferuatlı iş için GDI32.DLL

gösterilebilir.

Yukarıdakine benzer neredeyse x:windows klasörünüz altında ki executable sayısına eşit oranda api'ler mevcuttur, ve bunları kullanmak ve keşfetmek sizin programcılık ve ihtiyaç merakınıza doğru orantılıdır.

Benim gibi işi sadece şifre kırmak,exploit yazmak,hinliklerle uğraşmak gibi tembel işleriyle uğraşanlar için yukarıdaki api'ler yeterde artar bile. Ama unutulmamalıdırki iyi bir win32 programcısı api'leri kullandığı programlama dilinin komutları kadar iyi bilmeli ve kullanabilmelidir. Ancak o zaman ortaya yetenkli ve işlevsel bir program çıkar.

Evet kaldığımız yerden devam edersek. Programcılar WinApi'leri ile çalışmadan önce kullandıkları programlama diline hangi api'ler ile çalışacaklar ise bunu compilerlerine belirtmek zorundadırlar. Tabi bazı programlama dilleri bunu otomatik yapmıyor değil ama şunu unutmayın ki ne kadar hazır kod o kadar çok filesize demektir. Sadece size yarayan api'leri import etmeniz hem kodunuzun boyutunu korur hem de hızını.