dll kullanımı ile ilgili 2 soru

[The_Cuisinart]

Selamlar;

Konunun başlığını detaylandıramadım,çünkü sormak istediğim şeyler bir parça birbirlerinden kopuk durumdalar.

1-Şimdi kendi yarattığımız bir class'ı export eden bir .dll yazıp,bunu bir .exe dosyasına bağlıyoruz.MSDN'den okuduğuma göre biz .exe dosyasını çalıştırdığımız anda sistem .dll'in içindeki class'ı,onun üye fonksiyonlarını ,değişkenlerini ve dll'deki diğer global fonksiyonları bizim .exe dosyamızın bellek alanına yazıyor (.lib dosyası ile dll'in en başta otomatik olarak yüklendiğini farz ediyorum,implicit linking hesabı). Fakat öte yandan,.dll içerisindeki bir DllCreateClassObject(CObj** ppObj) tarzı fonksiyonla yine .dll içerisinde, dinamik olarak bir CObj yarattığımız zaman, exe içerisinde bunu

[devreci]

The_Cuisinart bir önceki açtığın formunda yazmıştım. Ama okumadın heralde gittin msdn'ye hemen, illa gevurcamı yazıcaz.

senin exe'nin .idata bölümünde kullanmak istediğin fonsiyonların adları yazar. Windows senin exeyi çalıştırıken dll'deki istediğin fonksiyonları
hafızaya yükler ve "Adresini" senin exenin .idata bölümüne gerekli olan yere yazar sende dll fonsiyonunu çağırırsın

tıpkı bunun gibi:
asm

call [498878..] bu sayı senin exenin üzerinde bulunan boş bir yerdir oraya windows dll fonsiyonun hafızasındaki yerini atar sende çağırır kullanırsın.
dll fonsiyonu senin programın içinde normal fonsiyonla aynı biçimde kullanılır.


mesela:

push 12
push yazi
push 0
push 0
push [hdc]
call [4785....] ;textout c'de textout(hdc,0,0,yazi,12) karşılığı


normal fonsksiyon

int kare(a,b)
{
a=a*b;
return a;
}

c de fonsiyon dönüşünde return edilen sayı eax registeriyle döner

bu böyle çağırılır asm de aynı yani:

push a
push b
call kare ;; burda adres bilindiği için direk çağırılır yani hafızanın içindeki sayıyı değilde direk adres çağırılır.


yani gl'de fonsiyonlar bu şekilde çağırıldığı için hiçbir zayıflama olmaz.

Release komutu bir fonsiyondur "c++ deki bir yapı" değildir. Mesela

Texture->release() ; dersen ekran kartındaki ayrılan yerler geri verilir
ekran kartına.. Biton iş yapar yani.

push -> stağa veri gönderir
call -> cpu bir adrese atlar ordaki komutları işler "ret" ile geri döner

Kusura bakma ASM dışı anlatabilmem imkansız.
c++ bilenler anlatsın benden bukadar

[The_Cuisinart]

[devreci]

evet hocam o sayının gösterdiği hafızanın içine windows dll fonksiyonunun adresinin başlangıç yerini yazar. Bu nedenle her zaman aynı sayı çıkmaz.
kare fonksiyonunun yeride exe içinde bellidir.

Com da ise o sayı içindeki sayının içinde sırasıyla fonksiyonların yerleri yazılıdır. Bizim için tek farkı fonksiyonu adı ile değil numarası ile çağırmamız.

mesela:

push matrix
push 2 ; transform view:)
mov ebx,[d3d] ;;;d3d interfacede windowsun bize verdiği adres
push ebx
mov eax,[ebx]
call [eax+148] ;;;;;;settransform fonksiyonu çayırdım

yani 3 satır asm fazlam var. normalde bir satırda çağırıyorum
call [glpushm] vs gibi

[lucifer]

hodo...
o kadar basit degil. dll icinde 'new'ledigin birseyi dll icinde 'delete' etmek durumunda kaliyorsun. Sebebi de suna benzer birsey (%100 dogru olmayabilir ama %99 dogru) : windows dll'in kullandigi memory'i birden fazla .exe'ye mapleyebilir.. sonucta 10 tane process o dll'i kullaniyorsa, hepsi de dll'in kendilerine ait birer kopyasi oldugunu zannedecektir, ama aslinda yoktur, dll'in fiziki ram'de sadece tek kopyasi vardir, di mi.. dll'in kendine gore bir address space'si olmasi gerekir yani.. yani tam boyle degil de buna benzer birsey...

simdi bu kopyanin icinde bir 'new' komutu calisigini dusun.. dondurdugu adress hani process'in memory space'sinde olacak? :))

Concordantly, ergo, vis-a-vis.. dll icinde alloc ettigin pointeri dll icinde dealloc et.

Bunun overhead'ina gelince de, zaten windows'da hersey kendi address space'inde calisiyor, yani programin kullandigi adreslerin hicbiri gercek fiziksel adresler degil.... normal bir program bir func cagirirken ne kadar penalty yiyorsan aynisini yersin...yani tam aynisini degil sanirim bir-iki instruction fark var. frame basina 100,000 milyon kere glVertex3F cagirmazsan olculebilir bir fark olusmaz.

Devreci: COM'un bunlarla alakasi yok. COM'da function pointer'lar dynamic olabilir, object'lere runtime'da baglanabilir, COM ile DLL arasinda zerre benzerlik yok. COM'da zart diye function pointerine jumplamazsin. O function pointeri o DLL'in icinde olmayabilir, hatta o PC'nin icinde de olmayabilir, networkdeki baska bir makinada da olabilir, DCOM olabilir o adres..

zaten function pointer dersen com'un essence'sini pas gecmis olursun.. orada hersey interface, o interface'lere ulasmani saglayan sey de com interface manager, coCreateInstance dedigin zaman o interface'i support eden obceyi sen yaratmiyorsun, dll'deki bir offset'e jum etmiyorsun, o adresi sana COM veriyo., dedigim gibi o adres network'deki baska bir makinada da olabilir ve ona ulasmak icin, salliyorum, encryption'a, kerberos authentication'a ihtiyacin olabilir..Sen de ne sorarlarsa mov eax, 13; int 10h; diye cevap veriyorsun. When all you have is an hammer, everything begins to look like a nail.

ah ulan sensei olacakti da cevap yazacakti bu soruya.

[lucifer]

Ziiirnn...
bir ii sey daha.
bir com dll'i memory'e yuklendigi zaman illa onu yukleyen process ile ayni address space'de olacak diye birsey yoktur. eger com objecini inproc olarak cocreate etmezsen, o obje senin processin disinda baska bir process'e yuklenir.

aslinda soyle desek daha bir rahat anlasilabilir belki.

bir dll'in icine bir c++ class'i koydun ve export ettin ya..
onun yerine soyle yap.. bir .cpp ve bir .h'dan olusan bir dll dusun.
.cpp icine class'in tanimini ve implementasyonunu yaz.
class XBitmap olsun mesela bu.
sonra .h icinde sadece XBitmap'in PUBLIC methodlarindan olusan bi class yaz - XBitmapInterface.
butun XBitmapInterface metodlari virtual yap ve XBitmap'i XBitmapInterface'den derive et.
.h icinde

[devreci]

lucyfer sen hala c++ dan örnek veriyorsun. cpu da cointa.. intsance..
vs bu gibi naneler yok. Eğer bu kadar iyi biliyosun bu işleri bu COm'u
makine nasıl işliyor anlat bi. Mesela DCOM dan bir fonsiyonu çalıştırıken
cpu neler yapıyo aydınlat bizi .

[devreci]

birde com ile dll arasında benzerlik yok diyorsun com göktenmi inecek. cpu'nun çalıştırabildiği dosyalarda yada hafızada olacak

[mentat]

@devreci: sevgili devreci, cpu'ları ve asm'yi sevmeni ilgiyle takip ediyorum. kolay gelsin ama alakalı alakasız her konuyu cpu'ya taşımanın da bi alemi yok. eh, com da dll de exe de çalıştırılabilen (executable) dosyalar. onu biliyoruz hepimiz. yapısal olarak alakaları yok, işlevsel olarak illa ki aynı işleve sahipler bi şekilde. cpu ne alaka ya.

[The_Cuisinart]

Lucifer, cevaplar için sağol.COM nedir, ne değildir ince ince anlıyorum; MSDN'de "FROM CPP TO COM" diye bayağı güzel bir döküman var,adamın biri sağolsun üşenmemiş,oturmuş, dll içindeki basit bir C++ sınıfını adım adım bir COM objesine dönüştüren bir döküman yazmış.Bastım 44 sayfa tuttu,koçyiğit bir abiymiş demekki.Gerçi döküman tam 10 yıllık ama olsun.İnceliyorum şu aralar.

Dll fonksiyonlarının overhead mevzusuna gelince,üşenmedim ne olup bitiyor diye basit bir konsol programına kendi yaptığım bir dll'i ekledim.Dll içinde void A() diye global bir fonksiyon var,exe'nin void B() diye bir global fonksiyonu var.

B()
call @ILT+65(B) (0041....)
diye,

A()
mov esi,esp
call dword ptr [__imp_AHedeHodo (0045....) ]
cmp esi,esp
call _chkesp (00409...1)

diye çağrılıyor.Dediğim gibi asm'den anlamam fakat B() fonksiyonu exe'nin kod sectionu içinde neredeyse, o (0041....) sayısı orayı gösteriyor,compiler B() gördüğü her yerde cpu'nun direk o adrese atlaması için gerekli olan kodu yazıyor sanırım. A() ise aslen function pointer mantığı ile çalışıyor,__imp_AHedeHodo,yani (0045....) adresinde aslında dll fonkisyonunun "kendisi" değil,"adresi" var.(0045....) adresindeki adrese gidip fonksiyonu çalıştırıyor cpu.Bir nevi indirection galiba.Direct,indirect addressing diye iki farklı olay bunlar yine galiba ama en iyisi burda durayım ben,çok low level mevzular, maymun olmam tehlikesi var.

Son olarak dll'de memory alloc konusuna gelirsek;
Olayı başlarda yanlış yorumladım,zira benim deneme için yaptığım dll 3-5 gudik matematik işlemi yapan methodlara sahip bir class export ediyordu,bunu yükleyip kullanan sadece benim client programım vardı doğal olarak.Ama kernel32.dll falan gibi cevval sistem ve runtime dll'lerini haliyle her process ayrı ayrı kullanmak zorunda.Yalnız tam bu noktada bazı kavram karmaşaları yaşıyorum, şimdi "dll'in bellekte bir örneği var,windows bunu processlere map eder."Buradaki mapping işleminden kasıt sisteminin processlere dll fonksiyonlarının pointerlarını vermesi değil mi? Böylece birsürü prosesin bellekteki tek bir fonkisyona birsürü pointeri olacak.
Bir de address space kavramı,her prosesin fiziksel bellekte kendine ait adres alanları var diyoruz.Fakat "Kullandığı adresler gerçek fiziksel adresler değil" ne anlama geliyor ? Ha bir de,bir prosesin içindeki pointer'ın başka bir prosesin adres alanındaki bir fonksiyona falan işaret etmesi illegal bir mevzu değil miydi,sanki ben öyle hatırlıyorum ilk C++ öğrendiğim zamanlardan.

Neyse, herkese hayırlı işler.

[lucifer]

[The_Cuisinart]

Lucifer,hocam nasıl oluyor bu yahu,dediklerinden hiçbir şey anlamadım.

Benim bildiğim bir virtual memory mevzusu vardı,o da RAM'da yer kalmayınca windows'un harddisk üzerinde RAM'ı taklit eden bir dosya oluşturmasıydı.

Yani şimdi biz
int x;
diye bir integer'in &x diye adresini aldığımızda çıkan o afilli 0x0045A1 bilmemne sayısı bize onun fiziksel adresini vermiyor mu?????

Yıkıldı tüm gençlik hayallerim,canevimden vuruldum.

[lucifer]

[The_Cuisinart]

Lucifer,abi iyi hoş diyorsun da şimdi ben bir Ctrl+Alt+Del yaptığım zaman 44 ayrı çalışan process görüyorum(Hakikaten).Bunlardan mesela Ahmet adlı program 1000 integer kullansa bunun 1000 ayrı adresi olucak,Mehmet adlı program 3500 tane float kullansa onların 3500 ayrı adresi olacak,Hasan 500 tane kendi tanımladığı bir classtan kullansa onların 500 ayrı adresi olacak.Kalan 41 tanesi de ayrı.Şimdi virtual address table'ın bunca değişkenin,datanın virtual adresine karşılık fiziksel adres tutması sırf bu üç program için 1000+3500+500=5000 tane bölüme karşılık geliyor,diğer 41 processi de ekle yani bu table başlı başına devasa bir yapı haline gelmez mi?????

Hız mevzusuna hiç girmiyorum,elbet virtual-physical dönüştürme yapması için alengirli bir sürü ayrı chiptir,devredir vardır elbet.

Ha bir de 44 process yüklü olduğu halde benim 512 mb RAM'ın yarısı boş.Yani doğası gereği böyle yüzlerce megabyte bellek isteyen bir sürü program vardır elbet, ama belleğin tamamen dolup diske yazdığına çok şahit olmadım bilgisayarın.(Zaten swap yapınca disk langır langır ötüyor,hız inanılmaz derecede düşüyor.)Yani ciddi bir şekilde RAM yetersizliği çekildiği bir zamanda bu virtual memory sistemine geçilmesi daha mantıklı olmaz mıydı?RAM'ın yarısı boşken sistemin virtual-physical çevrimi biraz fuzuli gibi geliyor?

[lucifer]

Ahmet 1000 tane integer kullanirsa bunlarin cogu stack'de olacak zaten. program da onlara stack+12'deki int'i float'a cast et, bir arttir, stack + 15'deki float'a yaz gibi kullanacak. yani, makina dili adreslemenin cogu zaten relative (izafi). if (..) then (...) endif diye bir kalipta, eger if'in icindeki TRUE degilse endif'e jumplar ya... o jumpladigi yer zaten gercek bir adres degildir, (jump 15_byte_ileri) gibi birsey...

bir de adressler virtual demek, her byte adresi tek tek tablolarda tutuluyor degil, fiziki ram 4 kb'lik bloklara bolunmus durumda, bu bloklarin adresleri tutuluyor.

soyle aslinda
44 process'in hepsinin kendi virtual address table'i var. buna processin kendisi de ulasamaz, islemci seviyesinde kullanilan birsey bu.

misal process 21, 0x4c7c6fb82934 diye bir adresten data okuyacak.

windows bir process'e switch ettigi zaman cpu'nun 'es' ve 'di' register'larina process'in virtual address table'sinin indeksini yazar. process 21 icin bu adres 0x0011223344 fiziki adresi olsun.

process 21 aktif ve 0x4c7c6fb82934 adresinui okuyacak.

her adresin ilk bilmemkac biti, o adresi kullanan process'in virtual adress tablosuna bir indextir.

process 21 ve 0x4c7c6fb82934 adresi icin bu deger 0x4c7c olsun.

her offsette 4 kb'lin continuous fiziksel bir adres datasi bulunur.

cpu es:di'den 0x0011223344 degerini okuyarak tablonun ofsetini bulur..
buna 0x4c7c ekleyerek 0x0011223344 + 0x4c7c diye bir fiziki address bulur.
bu fiziki adresin 0x4c7c6fb82934 - 0x4c7c00000000'inci offseti, process'in ulasmak istedigi fiziki adrestir.
butun bunlarin yapilmasi 0 (zero) clock cycle surer. pipeline icinde bu is icin ozel atanmis transistorler var cunku.

detayli bilgi msdn + google.

bu arada, bu mac'da da boyle linux'da da boyle.