Visual Basic 2005 Coach



Dovnload 477.64 Kb.
Pagina6/13
Datum20.08.2016
Grootte477.64 Kb.
1   2   3   4   5   6   7   8   9   ...   13

6.2. Wat steekt er in assemblies?

In de vorige paragraaf hebben we besproken hoe Visual Basic-code omgezet wordt in een assembly-bestand. Een voordehandliggende vraag is uiteraard wat er nu in zo’n assembly steekt. Hierop gaan we nu kort in.



6.2.1. Over PE-bestanden

Sinds oudsher steunt het Windows-besturingssysteem op een bestandsformaat genaamd PE om uitvoerbare bestanden in op te slaan. Deze kunnen namelijk door Windows ingelezen worden om nadien uitgevoerd te worden. U werkt dagelijk met dergelijke bestanden zoals .exe-bestanden. PE staat voor Portable Executable. Zowel .dll als .exe bestanden gebruiken dit PE-formaat en noemt men ook wel “image files”. Daarnaast zijn er ook zogenaamde “object files” waar we hier niet verder op ingaan en gebruik maken van een zusterformaat genaamd COFF (Common Object File Format).


Ook .NET-assemblies maken gebruik van dit PE-bestandsformaat maar daar houdt het grootste deel van de gelijkenis op. In plaats van klassieke instructies te bevatten die door de processor kunnen worden uitgevoerd (zogenaamde “native code”) bevatten assemblies onder andere IL-code, de “lingua franca” van alle .NET-talen die door de CLR begrepen wordt.
Tip: Indien u de Platform SDK op uw pc hebt geïnstalleerd, hebt u een tool genaamd dumpbin.exe ter uwer beschikking om de inhoud van PE-bestanden te bekijken op een “gebruiksvriendelijke” (voor geeks althans) manier.

6.2.2. Assemblies binnenstebuiten gekeerd

Zoals u reeds kunt vermoeden, bevatten assemblies de code (in IL-formaat) die overeenkomt met de – in ons geval – Visual Basic-code die u hebt geschreven en werd gecompileerd door de compiler. Assemblies bevatten echter meer dan enkel de code.



In de meeste gevallen bestaan assemblies uit één enkel bestand maar het .NET Framework heeft ook de notie van “multi-file assemblies” wat ons in het kader van deze “Visual Basic 2005 Coach” te ver zou leiden.
Assemblies dienen gezien te worden als basiseenheid voor de verspreiding van software. Zo bestaat een applicatie uit één of meerdere assemblies, eventueel aangevuld met andere bestanden zoals configuratiebestanden.

6.2.2.1. Metadata

Om te beginnen bevat een assembly zogenaamde metadata. Deze metadata beschrijft de inhoud van de assembly en is van groot belang om “xcopy deployment” van .NET-applicaties mogelijk te maken. In feite vormt metadata de hoeksteen van de oplossing tegen de DLL Hell uit het COM-tijdperk. We zeggen ook wel dat assemblies om die reden “self-describing” zijn. Ze bevatten alle informatie die tools of andere assemblies moeten weten om ermee samen te werken, zonder dat enige vorm van registratie nodig is.


Een eerste vorm van metadata is de assembly metadata en bevat informatie zoals de naam, versie en cultuur van de assembly. Deze informatie geeft de assembly een unieke naam (om helemaal correct te zijn is er ook een “public key token” die we voorlopig achterwege laten). Daarnaast bevat de assembly metadata ook informatie over de assemblies waarvan deze assembly afhankelijk is. Zo zal elke GUI-applicatie geschreven met “Windows Forms” afhangen van System.Windows.Forms.dll, de BCL-assembly die de Windows Forms code bevat. De assembly metadata noemt men ook wel de “manifest”.
Type metadata beschrijft de types die in de assembly zijn gedefinieerd, zoals klassen en interfaces en hun methodes. Indien u vertrouwd bent met C- of C++-programmatie (of andere talen) hebt u wellicht al gehoord van .h bestanden (header files) en .idl bestanden (Interface Description Language). Type metadata kan gezien worden als het equivalent hiervan in de wereld van .NET.

6.2.2.2. IL-code

Verder bevat een assembly typisch IL-code als resultaat van een eerder compilatie van de één of andere .NET taal. Hierop gaan we zo dadelijk nader in en zullen we zelfs deze IL-code eventjes van dichter bij bekijken. Nog eventjes geduld hiervoor.



6.2.2.3. Resources

Tot slot kan een assembly ook “resources” bevatten zoals bijvoorbeeld afbeeldingen of taalafhankelijke informatie indien het programma in meerdere talen beschikbaar is. Er bestaan zelfs assemblies die enkel resources bevatten, zoals “satellite assemblies” voor diverse talen.



6.2.3. IL-code van dichtbij

In wat vooraf ging hebben we vaak gerefereerd naar IL-code, of Intermediate Language. Laten we dit iets concreter maken door een blik te werpen op de IL-code van ons eerder geschreven “Hello World”-voorbeeldje.




  1. Keer terug naar het commandolijnvenster.



  2. Controleer of u zich in de map \HelloWorld\bin\Debug bevindt.



  3. Open de IL Disassembler voor de HelloWorld.exe assembly via het volgende commando:

    >ildasm HelloWorld.exe

    De wondere wereld van IL lacht u toe.



  4. U krijgt een venster zoals het volgende te zien:



    Opmerking: In feite is de naam IL Disassembler niet zo goed gekozen vermits je ook de manifest (synoniem voor assembly metadata) kan inspecteren. Een naam “Assembly Inspector” ware dus beter geweest.



  5. Neem eerst een kijkje onder de tak M A N I F E S T. Hierin ziet u dingen zoals (vereenvoudigde weergave):

    // Metadata version: v2.0.50727


    .assembly extern mscorlib
    {
    .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
    .ver 2:0:0:0
    }
    .assembly extern Microsoft.VisualBasic
    {
    .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )
    .ver 8:0:0:0
    }
    .assembly extern System
    {
    .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
    .ver 2:0:0:0
    }

    Hierin ziet u onder andere dat onze assembly afhangt van mscorlib (versie 2.0.0.0), System (versie 2.0.0.0) en Microsoft.VisualBasic (versie 8.0.0.0). De versie van de metadata verwijst naar de versie van het .NET Framework, in dit geval de “RTM-versie” 2.0.50727.

    Mscorlib is de “basisassembly” van het .NET Framework. In System steekt onder andere de klasse Console die we gebruikt hebben in ons programma. Let ook op de versie van Microsoft.VisualBasic. Na versie 6.0 kwam versie 7.0 als eerste .NET-versie van Visual Basic op het .NET Framework 1.0. Daarna kwam 7.1 voor het .NET Framework 1.1 en nu is 8.0 aan de beurt.



  6. Daal nu verder af in de boomstructuur in de IL Disassembler tool, tot bij de methode Main, zoals hieronder weergegeven:





  7. Open deze methode om een blik te werpen op de IL-code. De eigenlijke code ziet er als volgt uit:

    IL_0000: nop


    IL_0001: ldstr "Geef uw naam: "
    IL_0006: call void [mscorlib]System.Console::Write(string)
    IL_000b: nop
    IL_000c: call string [mscorlib]System.Console::ReadLine()
    IL_0011: stloc.0
    IL_0012: ldstr "Welkom bij Visual Basic 2005, {0}!"
    IL_0017: ldloc.0
    IL_0018: call void [mscorlib]System.Console::WriteLine(string,
    object)
    IL_001d: nop
    IL_001e: nop
    IL_001f: ret

    Vermoedelijk ziet u wel wat deze code doet (u hebt ze tenslotte zelf geschreven). U hoeft zich geen zorgen te maken over de details van deze code, het volstaat dat u een beeld hebt gekregen van hoe een stukje IL-code er uitziet in grote lijnen.



    Noot: Geeks onder de lezers zullen zich afvragen wat het grote aantal nop-instructies in deze code staat te doen. Maakt u zich geen zorgen, deze nop’s zijn enkel aanwezig in de “debug-build” van een programma en laten toe breakpoints te zetten op lijnen waar geen echte code staat (in ons geval zaken zoals End Main).




1   2   3   4   5   6   7   8   9   ...   13


De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina