Invoering

In de afgelopen 10 jaar was Windows het meest populaire (91,02%) besturingssysteem op de pc-markt. Windows-besturingssystemen draaien op x86-, AMD64-, IA-64-platforms. Er waren ook versies voor DEC Alpha, MIPS en PowerPC.

Windows NT-familie:

Besturingssystemen van deze familie werkten op processors met IA-32-architectuur en enkele RISC-processors: Alpha, MIPS, Power PC (tot versie 2000, die alleen werd uitgebracht in de versie voor IA-32). Windows NT is een volledig 32-bits besturingssysteem en heeft, in tegenstelling tot de versies 1.0–3.x en 9x, geen MS-DOS-ondersteuning nodig.

Windows NT 3.1 (1993)

Windows NT 3.5 (1994)

Windows NT 3.51 (1995)

Windows NT 4.0 (1996)

Windows 2000 (2000) - Windows NT 5.0

Windows XP (2001) - Windows NT 5.1

Windows XP 64-bit editie (2006) - Windows NT 5.2

Windows Server 2003 (2003) - Windows NT 5.2

Windows Vista (2006) - Windows NT 6.0

Windows Thuisserver (2007)

Windows Server 2008

Windows 7 (2009) - Windows NT 7.0 (huidige versie - 6.1)

De Windows NT-familie is gebaseerd op de scheiding van adresruimten tussen processen. Elk proces heeft de mogelijkheid om te werken met het toegewezen geheugen. Het heeft echter geen toestemming om naar het geheugen van andere processen, stuurprogramma's en systeemcode te schrijven.

De Windows NT-familie is een preventief multitasking-besturingssysteem, geen realtime besturingssysteem. De verdeling van de processortijd tussen threads gebeurt volgens het "carrousel"-principe. De kernel van het besturingssysteem wijst beurtelings een tijdschijf toe (in Windows 2000 is de schijf ongeveer 20 ms) aan elk van de threads, op voorwaarde dat alle threads dezelfde prioriteit hebben. Een thread kan zijn toegewezen tijdsegment opgeven. In dit geval neemt het systeem de controle van hem over (zelfs als de toegewezen tijdspanne nog niet voorbij is) en draagt ​​het de controle over aan een andere thread. Bij het overdragen van de besturing naar een andere thread, slaat het systeem de status van alle processorregisters op in een speciale structuur in RAM. Deze structuur wordt de threadcontext genoemd. Het opslaan van de context van een thread is voldoende om het werk later te hervatten.

Een API (Application Programming Interface) is een reeks functies, meestal georganiseerd als een DLL. Met API-functies kunt u de interface tussen een applicatie en de omgeving waarin het programma draait, organiseren. Door API-functies aan te roepen, kan een programma toegang krijgen tot omgevingsbronnen en deze beheren. Typisch definieert een API een standaard voor interactie tussen de omgeving en de applicatie.

Win32 is de naam van een interface die is ontworpen voor 32-bits toepassingen en is geïmplementeerd op bekende platforms als Windows 95, Windows 98, Windows NT, Windows CE. De functies waaruit deze interface bestaat, stellen een toepassingsprogramma in staat om toegang te krijgen tot de bronnen van het besturingssysteem en deze te beheren. Eerdere versies van Windows gebruiken een interface die bekend staat als Win16. Natuurlijk zijn niet alle functies die deel uitmaken van de Win32-interface volledig geïmplementeerd op alle platforms, dus het oproepen van dezelfde functie onder NT zal een definitief resultaat opleveren, terwijl het onder Windows 95 werkt als een stomp-aanroep. Alle applicaties die in de Windows-omgeving draaien, direct of indirect, roepen functies aan die zijn opgenomen in de Win32 API.

De functies waaruit de Win32-interface bestaat, zijn georganiseerd als meerdere dynamische linkbibliotheken (DLL's) en uitvoerbare bestanden.

API-functies maken niet noodzakelijkerwijs deel uit van de Win32-interface. Zo zijn de Messaging Application Programming Interface (MAPI) functies voor het verwerken van e-mailberichten en zijn TAPI (Telephone API) functies voor het werken met telefoonberichten. MAPI, TAPI, evenals Win32, zijn een reeks functies die een bepaalde standaard voor interactie bepalen.

De functies waaruit de API bestaat, zijn meestal georganiseerd als DLL's - dynamische linkbibliotheken. Een van de voordelen van een DLL is dat het niet uitmaakt hoeveel applicaties (processen) werken met de functies van dezelfde DLL, de DLL-code bestaat in één enkele kopie.

1. Theoretisch gedeelte

1.1 Win32-functies voor het vinden van een lijst met lopende processen

programma-algoritme bibliotheek gebruiker

Win32 biedt verschillende manieren om lopende processen weer te geven. Helaas is er niet één manier die op alle Win32-platforms werkt. Programmeurs moeten verschillende methoden in één programma combineren om het op alle versies van Windows te laten werken.

1. Overweeg de volgende methoden:

2.De Process Status Helper (PSAPI)-bibliotheek gebruiken

3.De ToolHelp32-API gebruiken

4. De ongedocumenteerde functie ZwQuerySystemInformation gebruiken

5. Via prestatiemeters

6.Gebruik van Windows Management Instrumentation-interfaces

7. Socket-interfacefuncties:

1.2 De processtatushelperbibliotheek gebruiken

De Process Status Helper-bibliotheek, ook bekend als PSAPI, biedt een reeks functies die informatie verschaffen over processen en apparaatstuurprogramma's. De bibliotheek wordt geleverd met Windows 2000 / XP en is beschikbaar als installeerbare component voor Windows NT 4.0.

Om processen op te sommen, biedt de bibliotheek de functie EnumProcesses, die een reeks lopende proces-ID's retourneert. Hieronder staat de tekst van de functie EnumProcesses_PsApi die procesopsomming implementeert met PSAPI.

Met de functie EnumProcesses weet u niet hoeveel ruimte er nodig is om de hele reeks id's te accepteren. Daarom noemen we het in een lus, waarbij de grootte van de buffer wordt vergroot totdat de grootte van de geretourneerde array kleiner is dan de grootte van de buffer.

Omdat we naast de proces-ID's ook de namen van de processen willen krijgen, moeten we extra werk doen. Voor elk proces krijgen we eerst het handvat met behulp van de OpenProcess-functie en gebruiken vervolgens de EnumProcessModules-functie, die een lijst met modules retourneert die in de adresruimte van het proces zijn geladen. De eerste module in de lijst is altijd de module die overeenkomt met het EXE-bestand van het programma. Ten slotte roepen we de GetModuleFileNameEx-functie aan (die ook deel uitmaakt van de PSAPI) om het pad naar het EXE-bestand te krijgen met behulp van de moduledescriptor. We gebruiken de naam van het EXE-bestand zonder het pad als procesnaam.

Er moet aandacht worden besteed aan de speciale behandeling voor de twee processen. We zijn genoodzaakt om het inactieve proces (Idle) met ID 0 en het systeemproces (Systeem), dat ID 2 heeft op Windows NT 4 en 8 - op Windows 2000 / XP afzonderlijk te verwerken, omdat OpenProcess niet toestaat dat een handvat wordt geopend voor deze processen door foutcode ERROR_ACCESS_DENIED te retourneren.

RTOS wordt opgeslagen vanuit de kern, de procesmanager en uitgebreide services op basis van de koristuvach. Als referentie voor een micro-core besturingssysteem, implementeert QNX Neutrino RTOS alleen de meest fundamentele diensten in de OS-kern, zoals het verzenden van signalen, timers, het plannen van streams, over het "synchroniseren van de besturingssystemen. ..

De voorziening is toereikend voor de oplossing van de in het bestek gestelde taak. 4. SOFTWARE-IMPLEMENTATIE VAN HET VERMELDE PROBLEEM De software-implementatie van de hierboven ontwikkelde applicatiestructuur bestaat uit de ontwikkeling van een uitvoerbare Win32-applicatie in de visuele programmeeromgeving MS Visual Studio. Een softwareproject bestaat uit drie klassen: CFuzzyApp, CFuzzyDlg, CFuzzy_. v...

Uitgifte en acceptatie van licenties). In de omstandigheden van grote netwerken wordt aanbevolen om een ​​aparte computer (of meerdere voor redundantie) licenties voor de server toe te wijzen. 1.1 Architectuur van eindapparatuur In computertechnologieën veronderstelt een drielaagse architectuur, synoniem met drielaagse architectuur (in het Engels three-tier of Multitier-architectuur) de aanwezigheid van de volgende applicatiecomponenten: ...

Toegang, dan stapt de eigenaar van de server niet naar de politie, maar huurt een hacker in en "vult het gat" in de bescherming. HOOFDSTUK 2. STRAFRECHTELIJKE JURIDISCHE KENMERKEN VAN MISDADEN OP HET GEBIED VAN COMPUTERINFORMATIE 2.1. Illegale toegang tot computerinformatie Artikel 272 van het Wetboek van Strafrecht van de Russische Federatie voorziet in aansprakelijkheid voor illegale toegang tot computerinformatie die door de wet wordt beschermd, d.w.z. informatie over ...

Vertaling: A. Nikolaev
S. Joesjtsjenko

Dan Hildebrand
Senior architect, R&D
QNX Software Systems Ltd.

Invoering

De wijdverbreide acceptatie van Windows 95 en Windows NT heeft geleid tot een vraag naar embedded real-time besturingssystemen die de broncode kunnen aanpassen die is geschreven voor de Win32 API. Als reactie hierop ontwikkelen verschillende leveranciers momenteel producten die "ongeveer" de realtime-mogelijkheden van Windows NT vertegenwoordigen. Helaas is Microsoft terughoudend in het verlenen van toegang tot de Windows NT-broncode, waardoor deze realtime extensies buiten het besturingssysteem draaien. Een dergelijke implementatie is om "real-time extensions" rechtstreeks in de laag te injecteren die NT van de hardware scheidt ( NT hardware-abstractielaag) of HAL. Een andere add-on voert NT uit als een taak onder controle van een realtime besturingssysteem, samen met andere processen die als afzonderlijke taken worden uitgevoerd. Beide uitbreidingen vereisen aanpassingen aan de HAL, de eerste meer dan de laatste.

Maar er is een andere, totaal andere versie van de benadering van dit probleem. Het bestaat uit het implementeren van de Win32 API op een besturingssysteem dat speciaal is ontworpen om in realtime te worden uitgevoerd, waardoor Win32-applicaties in realtime kunnen worden uitgevoerd op hetzelfde niveau als native OS-applicaties. In dit artikel bekijken we de voor- en nadelen van deze opties.

Realtime gedaan binnen HAL

HAL is de onderste softwarelaag die Windows NT met de hardware verbindt. Het biedt hardwarecommunicatiefuncties zoals interrupts, video, diskettestations, enz. Door de HAL te wijzigen, kunt u code toevoegen die een timerinterrupt onderschept en tot op zekere hoogte in realtime wordt uitgevoerd.

Aangezien hardware-interrupts eerst worden afgehandeld door HAL en vervolgens worden doorgegeven aan het besturingssysteem, heeft HAL uit de eerste hand voorrang op het besturingssysteem. In plaats van een interrupt onmiddellijk te verzenden, kan de HAL besluiten deze te gebruiken om de dispatcher binnen de real-time kernel te besturen. Als reactie hierop kan de coördinator in realtime een reeks residente HAL-taken starten. Omdat de interrupts niet werden onderschept door de realtime-kernel, kunnen ze worden doorgegeven aan NT voor verdere verwerking, en kunnen NT-toepassingen worden gestart volgens de CPU-cycli die niet langer worden ingenomen door realtime-taken die binnen de HAL worden uitgevoerd.

Het probleem is dat dit realtime werk "onzichtbaar" is voor de rest van het systeem (behalve de CPU-cycli die verloren gaan voor de realtime kernel en taken die binnen de kernel worden uitgevoerd). Namelijk, realtime HAL-residente taken hebben geen directe toegang tot de volledige service van Windows NT (GUI, diskdrives, netwerk, etc.). Als gevolg hiervan moeten ontwikkelaars die deze methode overnemen manieren vinden om HAL-residente taken interoperabel te maken met NT-toepassingen die kunnen volledige toegang hebben tot de volledige service:

Voor-en nadelen

Met de op HAL gebaseerde methode wordt de Windows NT-omgeving slechts licht gewijzigd, wat betekent dat het besturingssysteem compatibel is met apparaatstuurprogramma's en andere extensies. Maar deze optie heeft verschillende nadelen:

Geen compatibiliteit tussen standaard en realtime omgevingen

Het komt erop neer dat de real-time kernel in de HAL ofwel een zeer kleine set Win32-functies zal hebben, ofwel een compleet andere set tools. Hierdoor moeten realtime processen op een heel andere manier worden geprogrammeerd dan reguliere NT-programma's. Het overzetten van code tussen NT en HAL wordt moeilijk.

Niet-standaard ontwikkelomgeving

Door het verschil in structuur en code van applicaties, zullen de tools voor het ontwikkelen en debuggen van realtime applicaties ook verschillen van de tools voor het maken van conventionele applicaties. Er is enige training vereist voordat u kunt beginnen met het ontwikkelen van realtime problemen.

instabiliteit

Het feit dat real-time taken die in HAL worden uitgevoerd, vrij onstabiel zijn in gebruik, wordt als vanzelfsprekend beschouwd. Terwijl de NT-omgeving MMU-bescherming biedt voor veelvoorkomende taken, kunnen bugs in de code van HAL-residente real-time applicaties gemakkelijk leiden tot de volledige crash van NT (“Blauw scherm”). Als gevolg hiervan is de ontwikkelomgeving vrij kwetsbaar. Bovendien zijn real-time toepassingen die op de HAL draaien niet bestand tegen globale storingen van NT zelf.

Extra overheadkosten

De HAL-implementatie die in de pers wordt beschreven, maakt gebruik van een "interrupt polling"-methode om onderbrekingen in realtime af te handelen, die werkt op een hoge, constante frequentie (20.000 Hz). Deze onderbreking met vaste snelheid introduceert extra systeembrede planningsoverhead, waardoor de onderbreking wordt afgehandeld wanneer er geen realtime werk vereist is. Ook neemt de wachttijd voor het starten van het werk toe, omdat realtime-gebeurtenissen niet kunnen worden verwerkt tot het volgende polling-interval. Een echte realtime-kernel is gebeurtenisgestuurd en reageert onmiddellijk op onderbrekingen op het moment dat ze zich voordoen.

Grote geheugenvereisten

Het gebruik van de HAL-extensie voegt alleen maar toe aan de toch al grote geheugenvereisten van NT. Als gevolg hiervan blijft deze oplossing onbevredigend voor veel real-time systemen met beperkte geheugencapaciteit die zouden kunnen profiteren van de Win32-interface.

Realtime implementatie buiten Windows NT

De tweede optie voor het toevoegen van real-time mogelijkheden aan Windows NT is om NT uit te voeren als de taak met de laagste prioriteit onder controle van het real-time besturingssysteem. Aangezien andere taken met een hogere prioriteit dan NT kunnen worden uitgevoerd, kunnen ze de NT-uitvoering pauzeren en een beter realtime determinisme bereiken. Voor een grotere betrouwbaarheid werken deze taken in een aparte adresruimte van NT:

Helaas deelt deze methode veel van de belangrijkste nadelen van de hierboven beschreven HAL-extensiemethode. De ontwikkelaar moet, net als voorheen, met twee totaal verschillende interfaces werken en daartussen kiezen, afhankelijk van of hij realtime determinisme nodig heeft of niet. De ontwikkeltools voor deze toepassingen zijn heel verschillend. Het overzetten van uw broncode tussen deze omgevingen is moeilijk. Nogmaals, de geheugenvereiste voor deze omgeving is aanzienlijk hoger dan alleen Windows NT.

Ondanks de nadelen van beide methoden, heeft de mogelijkheid om tot op zekere hoogte realtime ondersteuning toe te voegen aan standaard Windows NT een positieve kant - met name de compatibiliteit met Windows NT blijft grotendeels behouden. Omdat beide methoden echter hun eigen interfaces toevoegen, doen ze de geest van de samenhangende "open systeem" -omgeving die de afgelopen jaren zorgvuldig is gebouwd, teniet.

In plaats van een besturingssysteem (Windows NT) te nemen waarvan de broncode niet beschikbaar is en te proberen er realtime mogelijkheden aan toe te voegen, is het veel beter om Win32-applicaties te laten draaien op een besturingssysteem dat specifiek is ontworpen om in realtime te draaien. Een voorbeeld van een dergelijke techniek is de implementatie van de Willows Win32-toolkit in een op microkernel gebaseerd QNX®-besturingssysteem.

Win32 API toevoegen aan realtime besturingssysteem.

In een poging om de handige functies die POSIX in de UNIX-omgeving heeft gebracht in de Win32-wereld te introduceren, heeft de European Computer Manufacturers Association (ECMA) de Application Programming Interface voor Windows (APIW) aangenomen. Net zoals de POSIX-standaardgroepen POSIX exclusief binnen de interface definieerden, niet binnen de implementatie, zo heeft ECMA samen met OSF de APIW-standaard gedefinieerd. Het doel van de APIW is om een ​​Win32-interfacestandaard te definiëren voor de ontwikkeling van open systemen van platformonafhankelijke programma's die niet alleen hoeven te werken op besturingssystemen die afhankelijk zijn van Microsoft of Intel.

QNX bevestigt deze "implementatie-onafhankelijke" benadering: het is een high-performance microkernel-besturingssysteem dat ook de POSIX-interface ondersteunt. Net als de POSIX API kan de door ECMA gedefinieerde APIW worden overgenomen door QNX, waardoor het besturingssysteem een ​​krachtig realtime platform kan bieden voor het uitvoeren van applicaties die zijn geschreven voor de Win32 API. Deze aanpak elimineert veel van de nadelen die zijn beschreven voor de twee voorgaande methoden:

Duurzame omgeving

QNX introduceert een runtime-model dat minstens zo robuust is als Windows NT, met processen die in afzonderlijke MMU-beveiligde adresruimten worden uitgevoerd. Als gevolg hiervan is de realtime-omgeving die QNX biedt voor Win32-programma's "rigide" dan de omgeving waarin HAL-residente taken worden uitgevoerd zonder geheugenbescherming:

Compatibiliteit met standaard en realtime omgevingen

Realtime applicaties kunnen worden geschreven met volledige Win32 API-ondersteuning, inclusief GUI-toegang. Dit heeft veel de voorkeur boven het hebben van slechts een beperkte API binnen de HAL, of een OS-gestuurde native API die NT als taak uitvoert. Ontwikkelaars hoeven geen nieuwe set functies en ontwikkelingstools te leren, en bestaande Win32-broncode kan onmiddellijk worden gecompileerd en in een realtime omgeving worden uitgevoerd.

Geen overhead

QNX, als een gebeurtenisgestuurd realtime besturingssysteem, hoeft niet te peilen naar deze gebeurtenissen. Het besturingssysteem reageert alleen op hardware-interrupts wanneer ze zich voordoen, start de interrupt-handler en distribueert processen, en besteedt hier een minimum aan tijd aan, zoals typisch is voor een real-time besturingssysteem. Zo worden onnodige vertragingen en extra resourcekosten die samenhangen met realtime polling-gebeurtenissen geëlimineerd.

Compact platform

De implementatie van de Win32 API in QNX komt tot uiting in het feit dat de runtime compacter is dan Windows 95, en veel compacter dan Windows NT. Hoewel compact, biedt dit framework robuustheid met volledige geheugenbescherming, naast realtime determinisme, Win32 API en POSIX API-ondersteuning. Dit past veel meer bij ROM- of flashsystemen dan bij desktopbesturingssystemen zoals Windows NT.

Deze omgeving biedt een bijkomend voordeel: omdat QNX POSIX- en UNIX-compatibel is, kan UNIX-broncode ook worden gecompileerd en uitgevoerd. Het overdragen van UNIX-broncode naar het QNX-platform is net zo duur als het overdragen van broncode tussen verschillende versies van UNIX van verschillende fabrikanten. Als gevolg hiervan kunnen realtime systeemontwikkelaars de broncode veilig migreren van zowel de Win32- als UNIX-werelden naar hun realtime-omgeving. Dit minimaliseert de hoeveelheid code die helemaal opnieuw moet worden geschreven, en wat nog belangrijker is, helpt de time-to-market te verkorten.

QNX Win32 API-implementatie

Om de Win32 API in QNX OS te implementeren, hebben Willows Software () en QNX Software Systems het Willows RT-pakket naar QNX verplaatst en QNX-optimalisaties toegevoegd om de Willows-omgeving beter te laten werken. Dit pakket fungeert als een platformonafhankelijke interface tussen applicaties die de Win32 API aanroepen en het hostbesturingssysteem. Vanuit het oogpunt van toepassingsprogramma's fungeert deze interface, geïmplementeerd als een gedeelde bibliotheek, als de Windows-besturingssysteemomgeving met al zijn mogelijkheden en functies die het programma verwacht te zien. Vanuit het perspectief van een ontwikkelaar is het niet nodig om een ​​nieuwe omgeving te beheersen om bestaande Win32-applicaties opnieuw te compileren.

Willows RT is oorspronkelijk ontwikkeld als de Willows Toolkit voor het X Window-systeem voor Unix en de grafische Macintosh-omgeving. Hoewel er een X Window-implementatie voor QNX is, zou het draaien van Willows RT op X in een QNX-omgeving niet voldoen aan de compactheidsvereisten voor de realtime embedded markt. Dus, Willows RT is geport naar een op microkernel gebaseerd venstersysteem - Photon microGUI®, dat draait in de QNX-omgeving (zie Fout! Referentiebron niet gevonden. voor meer details). Photon kan dezelfde functies uitvoeren als het X Window, maar gebruikt minder geheugen (ongeveer 500 KB). Samen met de kleine omvang van QNX zelf, opent het een nieuwe oplossing, Willows-on-QNX, die veel minder geheugen vereist dan Windows NT en waardoor realtime Win32-applicaties kunnen worden uitgevoerd.

Willows API-componenten

Er zijn 3 hoofdcomponenten voor de Willows API:

• Willows binaire interface
• Wilgen Bibliotheek (Wilgen Bibliotheek)
• Willows Platform-abstractielaag

Willows binaire interface

Win32-applicaties werken op dezelfde manier samen met de Willows-bibliotheek als met de Windows-omgeving: API-functies aanroepen, berichten ontvangen, bronnen laden en zelfs andere Win32-applicaties starten. Bestaande Win32-applicaties en dynamische linkbibliotheken (DLL's) voor toegang tot Win32-API's op niet-Intel-platforms werken samen met het binaire bestand van Willows. (Deze interface leidt alle Windows API-verzoeken om naar de Willows-bibliotheek om buitenlandse toepassingen in staat te stellen native platformprestaties te bereiken.) Op dezelfde manier werkt de Willows-bibliotheek samen met het stuurprogramma door verzoeken te doen aan afbeeldingen, vensters of systeembewerkingen en antwoorden te accepteren, of asynchroon berichten.

De Willows API kan 16-bits Intel-objecten herkennen, zoals dynamische linkbibliotheken (DLL's), Visual Basic-richtlijnen (VBX), stuurprogramma's (DRV) en aangepaste besturingselementen van derden. Daarom kunnen ontwikkelaars broncodes en binaire modules combineren in een applicatieprogramma. Ze kunnen ook hun applicaties overdragen zonder te wachten tot iemand van "derde partijen" hun bibliotheken overdraagt. Gegevensbestanden en grafische bestanden kunnen ook zonder enige wijziging worden gebruikt, en programma's kunnen zonder enige wijziging gegevens uit de DLL blijven laden, wat de time-to-market zal versnellen.

Virtuele machine

De virtuele machine biedt een hardware-abstractielaag die de Intel-processor in beschermde modus nabootst. Deze laag beheert code- en datasegmenten, Intel-registers, interruptcontrole, instructies en I/O-simulatie. Alle bronadressen zijn toegewezen aan segment-/offsetadressen, inclusief dataadressen en Windows API-vensterfunctieadressen.

Voor het overzetten van Willows RT naar QNX, de native processor van Intel, is deze hardware-aanpassing niet nodig. Als gevolg hiervan kan native Wn32-code met de vereiste snelheid worden uitgevoerd, ongeacht of de Win32-broncode is gemigreerd of de besturingsomgeving van DLL's waarvoor de broncode niet beschikbaar is, is gewijzigd. Deze natuurlijke uitvoering behoudt het vermogen van programma's om realtime prestaties op het QNX-besturingssysteem te bereiken.

DOS-emulator

Een DOS-emulator bootst interrupts na en een functionele DOS-interface. Dit omvat alle DOS-functies die door de Win32 API worden gebruikt, inclusief procesbesturing en I/O. Parallelle en seriële poorten zijn toegankelijk door functies rechtstreeks toe te wijzen aan apparaten of uitgangsfilters.

QNX ondersteunt toegang tot native DOS-opslagmedia, die Willows RT gebruikt om bestanden te lezen en te schrijven naar media zoals harde schijven en diskettes. Hierdoor kunnen bestanden eenvoudig worden verplaatst tussen QNX/Willows-systemen en de native Windows/DOS-omgeving. Netwerkverbindingen via TCP / IP met SMB (of CIFS) en NFS kunnen ook worden gebruikt om netwerkbestanden te delen tussen QNX / Willows en Windows95- of Windows NT-systemen.

16/32-bits aanvraaghandler

De 16/32-bits Thunking Layer (16/32 Thunking Layer) manipuleert verzoeken tussen 16-bits Windows-code en de Willows-bibliotheek. 16-bits code werkt in een beveiligde modus met behulp van een 16-bits stapel en segment / offset voor adressering. Elk verzoek wordt geïdentificeerd door een "methode" die het overeenkomstige verzoektype afhandelt. Deze methode kan variëren van iets eenvoudigs, zoals het aanvragen van een bibliotheek en het retourneren van een resultaat in specifieke registers, tot complexere bewerkingen die adressen en datastructuren in beide gevallen transformeren, zowel tijdens het gesprek als bij het terugkeren van de procedure. ...

16/32-bits bootloader

16/32-bit Loader laadt programma's, distribueert programmacode en gegevens, dynamische linkbibliotheken en stuurprogramma's. De lader werkt in combinatie met de virtuele machine en de verzoekprocessor om code- en gegevenssegmenten op te nemen, inclusief ontbrekende segmenten, die later bij toepassingsverzoeken worden geladen. De lader koppelt ook de Willows-bibliotheek met de DLL om oproepen opnieuw toe te wijzen aan de bibliotheek.

Wilgen Bibliotheek

Om de Microsoft Windows API te implementeren, is de Willows-bibliotheek platformonafhankelijk gemaakt, waarbij de platformspecifieke code van de bibliotheek zelf wordt gescheiden en op een lager abstractieniveau van het platform wordt geplaatst. Om platformonafhankelijkheid volledig te garanderen, is de bibliotheek geschreven met behulp van de Win32 API zelf; hierdoor is het aantal functies dat op de platformabstractielaag moet worden geplaatst tot een minimum beperkt. Als gevolg hiervan blijft de Willows-bibliotheek platformonafhankelijk en wordt voor elk platform als native code gecompileerd voor maximale efficiëntie.

De implementatie van de Willows-bibliotheek is consistent en voldoet aan de APIW-vereisten die door ECMA en OSF zijn geïntroduceerd als een platformonafhankelijke Windows-API. Het is geschreven in C en biedt toegang vanuit zowel C- als C++-programma's.

Alle meest gebruikte Windows API-functies, met uitzondering van specifieke binaire startfuncties, zijn geïmplementeerd in de binaire interface. Het bevat alle standaard besturingsfuncties en klassen zoals type- en berichtklassen.

De bibliotheek ondersteunt:

• MDI-vensters, algemene dialoogvensters en functies voor dialoogbeheer

• implementatie van multitasking binnen één proces

• klembord en dynamische gegevensuitwisseling (DDE)

De bibliotheek slaat de eigenschappen van elk venster op en beheert lokale en globale atoomtabellen. Het heeft ook toegang tot native en binaire bronnen die dynamisch kunnen worden geladen en gelost onder controle van het applicatieprogramma.

Het voegt ook een complete set configuratie- en foutopsporingsfunctionaliteit toe aan de Windows API. Door met de foutopsporingsversie van de bibliotheek te werken, kan een toepassing de uitvoering van elke API traceren en diagnostische informatie verkrijgen over het programma terwijl het wordt uitgevoerd. De debugger die in de bibliotheek is ingebouwd, kan onafhankelijk of met conventionele debuggers werken om in realtime gedetailleerde informatie over de status van het programma te verkrijgen.

Platformabstractielaag

Dit niveau bevat alle platformspecifieke code voor het maken en manipuleren van vensters, weergave in die vensters en toegang tot systeemafhankelijke bronnen. Het bevat drie subsystemen die toegankelijk zijn via oproepen naar de Willows-bibliotheek:

Vensterbeheerdersinterface

Met de interface voor vensterbeheer kan de bibliotheek - in een platformonafhankelijke stijl - alle vensters beheren die een toepassing maakt. Het beheert functies zoals het maken en verwijderen van vensters, het vergroten of verkleinen van vensters en het verplaatsen van vensters, het maken en onderhouden van vensterbesturingsmenu's, het instellen van titels en pictogrammen voor geminimaliseerde vensters.

Alle communicatie met de desktop window manager gebeurt door platformspecifieke code, die vervolgens informatie doorstuurt naar het platformonafhankelijke deel van de windowmanager. De meeste externe gebeurtenissen die Photon vanuit grafische programma's levert, worden ook op dit niveau onderschept en vertaald in een standaardreeks opdrachten die de bibliotheek aankan. Deze gebeurtenissen omvatten berichten over het maken, opnieuw tekenen en verwijderen van vensters, en berichten over de locatie en grootte van vensters.

Grafische apparaatinterface

De Graphics Device Interface biedt een manier om afbeeldingen rechtstreeks op vensters of printers weer te geven. Het ondersteunt elementaire grafische bewerkingen zoals het tekenen van lijnen, rechthoeken en ellipsen, evenals meer complexe objectbewerkingen zoals pen, penseel, gebied en illustraties. Het heeft ook een volledige reeks functies voor tekstuitvoer, van lettertype- en kleurselectie tot speciale effecten zoals onderstrepen en doorhalen. De Willows Library en Graphics Device Interface ondersteunen een breed scala aan apparaten, van de eenvoudigste lage resolutie, beperkt kleurengamma, tot hoge resolutie displays met hoge kleuren en een breed scala aan printers. Al deze services worden rechtstreeks toegewezen aan de faciliteiten van de Photon microGUI.

Systeemservice-interface

De System Services Interface biedt platformafhankelijke code voor toegang tot bestandssysteemtools, geheugentoewijzing, netwerken en apparaattoegang. Het verschuift bijvoorbeeld alle netwerk- en communicatieverzoeken naar de juiste functies van het QNX-besturingssysteem. Het ondersteunt ook inter-task communicatie (IPC)-functies zoals klembord en DDE geïmplementeerd in de Willows-bibliotheek. Het bevat ook platformspecifieke code die is gekoppeld aan DLL's om de Willows Window Library in staat te stellen de semantiek van DLL's in QNX te ondersteunen.

Relatie tussen Win32-platforms

Aangezien u eenvoudig Win32-applicaties tussen Windows en QNX kunt porten, wordt het relatief eenvoudig om gedistribueerde real-time systemen te creëren waarbij elk knooppunt op het netwerk het besturingssysteem kan draaien dat het beste past bij de wensen van de gebruiker, maar waarbij alle knooppunten dezelfde dezelfde API gebruiken en toepassingscodes. Nu een programma gebouwd met dezelfde Win32-broncode op verschillende besturingssystemen op hetzelfde lokale netwerk kan draaien, wordt het natuurlijk belangrijk ervoor te zorgen dat deze gedistribueerde programma's met elkaar verbonden zijn. Om aan deze vereiste te voldoen, ondersteunt QXN SMB Network File Systems (CIFS) en NFS. Bovendien geeft Photon microGUI u de mogelijkheid om een ​​QNX-hostscherm (of een specifiek toepassingsvenster) te bekijken en te bedienen vanaf een Windows 95- of Windows NT-scherm. Als gevolg hiervan kunnen realtime grafische applicaties draaien op harde realtime platforms en worden weergegeven op conventionele systemen die op het netwerk zijn aangesloten.

Aanvullende QNX-services

Als een op microkernel gebaseerd realtime besturingssysteem, biedt QNX Win32-toepassingen een reeks services die niet beschikbaar zijn op Windows NT. Dit omvat robuuste realtime prestaties, gedistribueerde verwerking en een veerkrachtig netwerk.

Gedistribueerde verwerking die is overgenomen van QNX stelt u in staat een toepassing te bouwen als een groep van op elkaar inwerkende processen. Zonder de broncode te wijzigen, kunnen deze processen over meerdere processors worden verdeeld en blijven ze werken zoals voorheen. Bovendien kan een proces alle bronnen op elk QNX-knooppunt op het lokale netwerk gebruiken alsof die bronnen zich op de lokale computer bevinden.

Om maximale netwerkprestaties en veerkracht te garanderen, ondersteunt QNX meerdere netwerkverbindingen voor elke computer in het netwerk. QNX verdeelt automatisch de belasting van de netwerken, en als een netwerkverbinding mislukt, stuurt u de gegevens om via de bestaande netwerken.

Gevolgtrekking

Het is duidelijk dat de HAL-extensie en de host-OS-methoden werkbare opties bieden voor het toevoegen van realtime-mogelijkheden aan NT, maar tegen een prijs. Ze dwingen ontwikkelaars om te werken met aanvullende, zelfgemaakte API's en aangepaste ontwikkelingstools. Ze voeren realtime taken uit in een relatief volatiele omgeving. Bovendien verhogen ze de geheugenvereisten die NT al veel heeft.

Aan de andere kant stelt de implementatie van de Win32 API op het QNX realtime besturingssysteem ontwikkelaars in staat om slechts één API te gebruiken - Win32. Hierdoor kunnen realtime processen worden uitgevoerd in een betrouwbare omgeving met foutopsporing. En dankzij de geringe eisen die QNX stelt aan de hoeveelheid RAM, wordt het mogelijk om Win32 te gebruiken voor kleine embedded systemen.

Als een uitgebreid realtime besturingssysteem dat is geoptimaliseerd voor gebruik in foutkritieke toepassingen, biedt QNX de ontwikkelaar ook extra mogelijkheden zoals netwerkbestendigheid, gedistribueerde verwerking en volledige POSIX- en UNIX-compatibiliteit, wat vrijwel onmogelijk is op NT. Bovendien maakt QNX het relatief eenvoudig om Win32-platforms te combineren, waardoor de ontwikkelaar de vrijheid heeft om voor elke taak het juiste besturingssysteem te kiezen. Uiteindelijk vertegenwoordigt de Willows / QNX-ontwikkeling een samensmelting van een open source-mentaliteit en standaarden voor bronportabiliteit.

QNX en Photon microGUI zijn gedeponeerde handelsmerken van QNX Software Systems.
Alle andere handelsmerken en geregistreerde handelsmerken zijn eigendom van hun respectievelijke eigenaren.

Windows API - een set functies van het besturingssysteem

De afkorting API lijkt veel beginnende programmeurs erg mysterieus en zelfs intimiderend te zijn. In feite is de Application Programming Interface (API) slechts een kant-en-klare set functies die applicatieontwikkelaars kunnen gebruiken. In het algemeen komt dit concept overeen met wat vroeger een bibliotheek van routines werd genoemd. API verwijst echter meestal naar een speciale categorie van dergelijke bibliotheken.

Tijdens de ontwikkeling van bijna elke voldoende complexe applicatie (MyApplication) voor de eindgebruiker, wordt een set van specifieke interne functies gevormd die worden gebruikt om dit specifieke programma te implementeren, de zogenaamde MyApplication API. Vaak blijkt echter dat deze functies ook effectief kunnen worden gebruikt om andere applicaties te maken, ook door andere programmeurs. In dit geval moeten de auteurs, gebaseerd op de strategie om hun product te promoten, beslissen over de vraag: stellen ze de toegang tot deze set open voor externe gebruikers of niet? Als het antwoord ja is in de beschrijving van het softwarepakket, verschijnt de zin als een positief kenmerk: "De kit bevat een open set API-functies" (maar soms voor extra geld).

Dus meestal betekent een API een reeks functies die deel uitmaken van één applicatie, maar die tegelijkertijd beschikbaar zijn voor gebruik in andere programma's. Zo heeft Excel, naast een interface voor de eindgebruiker, een set Excel API-functies die met name gebruikt kunnen worden bij het maken van applicaties met VB.

Dienovereenkomstig is de Windows API een set functies die deel uitmaakt van het besturingssysteem zelf en die tegelijkertijd beschikbaar is voor elke andere toepassing, inclusief die welke zijn geschreven met VB. In dit opzicht is de analogie met de BIOS / DOS-systeemonderbrekingsset, die eigenlijk een DOS-API is, redelijk gerechtvaardigd.

Het verschil ligt in het feit dat de samenstelling van de Windows API-functies enerzijds veel ruimer is in vergelijking met DOS en anderzijds niet veel van de tools bevat voor directe controle van computerbronnen die beschikbaar waren voor programmeurs in het vorige besturingssysteem. Bovendien is de Windows API toegankelijk via gewone procedurele aanroepen, en worden DOS-functieaanroepen gedaan via een speciaal processormachine-commando genaamd Interrupt.

Waarom heb je Win API nodig voor VB-programmeurs?

Ondanks het feit dat VB een enorme verscheidenheid aan functies heeft, in het proces van min of meer serieuze ontwikkeling, blijkt dat hun capaciteiten vaak niet voldoende zijn om de noodzakelijke taken op te lossen. Tegelijkertijd beginnen beginnende programmeurs vaak te klagen over de tekortkomingen van VB en denken ze na over het veranderen van de tool, niet vermoedend dat er een enorme set tools op hun computer staat en dat je ze gewoon moet kunnen gebruiken.

Bij kennismaking met de Win-API ontdekt men dat veel ingebouwde VB-functies niets meer zijn dan oproepen naar de overeenkomstige systeemprocedures, maar alleen geïmplementeerd in de vorm van de syntaxis van deze taal. Met dit in gedachten wordt de noodzaak om de API te gebruiken bepaald door de volgende opties:

1. API-functies die volledig zijn geïmplementeerd als ingebouwde VB-functies. Desalniettemin is het in dit geval soms ook nuttig om over te schakelen naar het gebruik van de API, omdat dit soms de prestaties aanzienlijk kan verhogen (met name door het ontbreken van onnodige transformaties van de doorgegeven parameters).
2. Ingebouwde VB-functies implementeren slechts een speciaal geval van de bijbehorende API-functie. Dit is een vrij veel voorkomende optie. De CreateDirectory API is bijvoorbeeld krachtiger dan de ingebouwde VB MkDir-operator.
3. Een groot aantal API-functies heeft helemaal geen analogen in de huidige versie van de VB-taal. U kunt bijvoorbeeld een map niet verwijderen met VB - u moet hiervoor de functie DeleteDirectory gebruiken.

Ook moet worden benadrukt dat sommige API-functies (hun aandeel in de Win API is erg klein) niet kunnen worden aangeroepen vanuit VB-programma's vanwege een aantal taalbeperkingen, bijvoorbeeld vanwege het ontbreken van de mogelijkheid om met geheugenadressen te werken. Maar in sommige gevallen kunnen niet-triviale programmeertechnieken helpen (met name in het geval van dezelfde adressen).

Het persoonlijke standpunt van de auteur is dat in plaats van het uitbreiden van versie naar versie van ingebouwde VB-functies, een goede beschrijving van de meest voorkomende API-functies moet worden gegeven. Tegelijkertijd zou ik ontwikkelaars willen adviseren om niet te wachten op een nieuwe versie van de tool met geavanceerde functies, maar om de bestaande Win API nader te bestuderen - het is waarschijnlijk dat de mogelijkheden die u nodig hebt al in de VB 1.0-versie van de release van 1991.

Hoe Win API te leren

Dit is niet zo'n gemakkelijke vraag, aangezien het aantal Win32 API-functies wordt geschat op ongeveer 10 duizend (niemand kent het exacte aantal, zelfs Microsoft niet).

De VB (versies 4-6) bevat een bestand met de beschrijving van Win API-declaraties - WIN32API.TXT (we zullen u later meer vertellen over het gebruik ervan). Maar ten eerste kan het worden gebruikt om informatie te verkrijgen over het doel van een bepaalde functie en zijn parameters, alleen door de gebruikte geheugensteunnamen, en ten tweede is de lijst met functies in dit bestand verre van compleet. Er waren eens (zeven jaar geleden) in VB 3.0 speciale helpbestanden die de Win16 API-functies beschrijven. Echter, al in v.4.0 is deze nuttige informatie met een gebruiksvriendelijke interface verdwenen.

Uitgebreide informatie over de Win32 API is te vinden in de Platform Software Development Kit Help, die met name te vinden is op de MSDN-bibliotheek-cd's die zijn meegeleverd met VB 5.0 en 6.0 Enterprise Edition en Office 2000 Developer Edition. Het is echter helemaal niet eenvoudig om daar de nodige informatie te vinden en te begrijpen. Om nog maar te zwijgen van het feit dat alle beschrijvingen daar gegeven worden in relatie tot de C-taal.

De boeken van de bekende Amerikaanse expert Daniel Appleman worden in de wereld algemeen erkend als een gids voor het leren van API-programmering in de VB-omgeving. Zijn serie Dan Appleman's Visual Basic Programmer's Guide to the Windows API (voor Win16, Win32, toegepast op verschillende versies van VB) is sinds 1993 consequent een van de bestsellers geweest voor VB-programmeurs. Dan Appleman's VB 5.0 Programmer's Guide to the Win32 API, gepubliceerd in 1997, werd uit de Verenigde Staten naar de auteur gebracht door een vriend die het in de eerste boekhandel in een klein provinciestadje vond.

Dit boek, meer dan 1.500 pagina's, bevat een algemene methodologie voor API-programmering in de VB-omgeving, evenals meer dan 900 functies. De bijbehorende cd-rom bevat de volledige tekst van het boek en alle programmavoorbeelden, evenals enkele extra hoofdstukken die niet in de gedrukte versie waren opgenomen. In 1999 bracht Dan Appleman Dan Appleman's Win32 API Puzzle Book en Tutorial for Visual Basic Programmers uit, die informatie bevat over nog eens 7.600 functies (zij het minder grondig).

Win API en Dynamic Link Library (DLL)

De Win API-set is geïmplementeerd als dynamische DLL's. Verder zullen we het hebben over de technologie van het gebruik van DLL's in de VB-omgeving aan de hand van het voorbeeld van de bibliotheken die deel uitmaken van de Win API. Er zijn echter een paar belangrijke punten die u moet maken als u het over DLL's hebt.

In dit geval bedoelen we met DLL de traditionele versie van binaire dynamische bibliotheken die directe applicatie-aanroepen bieden aan de vereiste procedures - subroutines of functies (op vrijwel dezelfde manier als bij het aanroepen van procedures binnen een VB-project). Dergelijke bibliotheken kunnen worden gemaakt met verschillende tools: VC ++, Delphi, Fortran, behalve VB (laten we eens kijken wat er in versie 7.0 verschijnt) - de laatste kan alleen ActiveX DLL's doen, die toegankelijk zijn via de OLE-automatiseringsinterface.

Meestal hebben DLL-bestanden de extensie .DLL, maar dit is niet nodig (voor Win16 werd vaak de extensie .EXE gebruikt); externe apparaatstuurprogramma's worden geïdentificeerd met .DRV.

Zoals we hebben opgemerkt, is het moeilijk om het exacte aantal Windows API-functies en de bestanden die ze bevatten te bepalen, maar ze bevinden zich allemaal in de systeemmap. In dit opzicht is het beter om de samenstelling van de bibliotheken in de kernel van het besturingssysteem en de hoofdbibliotheken met belangrijke extra functies te benadrukken.

Nu een paar tips.

Tip 1. Zorg ervoor dat uw DL-advertentie correct is opgemaakt L-procedures

De daadwerkelijke aanroep van DLL-procedures in het programma ziet er precies hetzelfde uit als de "gewone" Visual Basic-procedures, bijvoorbeeld:

Bel DllName ([argumentenlijst])

Om externe DLL-functies (inclusief Win API) te gebruiken, moeten ze echter in het programma worden gedeclareerd met behulp van de verklaring Declare, die er als volgt uitziet:

Declareer subprocedurenaam Lib _ "Bibliotheeknaam" _ [([Argumentenlijst])]

Declareer functie Functienaam _ Lib "Bibliotheeknaam" _ [([ArgumentLijst])]

Hier worden tussen vierkante haken optionele elementen van de operator gegeven, variabele uitdrukkingen zijn cursief, de rest van de woorden zijn trefwoorden. Het help-systeem geeft een redelijk goede beschrijving van de syntaxis van de operator, dus voor nu zullen we slechts enkele punten opmerken.

Declaraties van externe functies moeten in de sectie Algemene declaraties van de module worden geplaatst. Als u het in een formuliermodule plaatst, moet u het sleutelwoord Private specificeren (deze verklaring is alleen beschikbaar binnen deze module) - dit is een beperking voor alle procedures van de formuliermodule.

De Win32 API-set is alleen geïmplementeerd als functies (er waren veel Subs in de Win16 API). De meeste zijn functies van het type Lang, die meestal een code voor het voltooien van een bewerking retourneren.

De verklaring Declare verscheen in MS Basic in de tijd van DOS en werd ook gebruikt om de interne procedures van een project aan te geven. In Visual Basic is dit niet vereist omdat de verklaring van interne procedures automatisch hun sub- of functiebeschrijving is. In vergelijking met Basic / DOS is het in de nieuwe beschrijving verplicht om de naam van het bibliotheekbestand aan te geven waar de vereiste procedure zich bevindt. De Wip API-bibliotheken bevinden zich in de Windows-systeemmap, dus alleen de naam van het bestand is voldoende. Als u verwijst naar een DLL die zich op een willekeurige locatie bevindt, moet u het volledige pad naar dit bestand noteren.

De omschrijving van het Declare-statement neemt meestal veel ruimte in beslag en past niet op één regel in het codevenster. Daarom raden we aan dat u zich houdt aan een specifiek regelterugloopschema bij het schrijven van toepassingen, bijvoorbeeld:

Declareer functie GetTempPath _ Lib "kernel32" Alias ​​​​"GetTempPathA" _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) Zo lang

In dit geval zijn alle hoofdelementen van de beschrijving op verschillende regels uit elkaar geplaatst en zijn daarom gemakkelijk te lezen.

Tip 2. Wees vooral voorzichtig bij het werken met DLL-functies

Het gebruik van Win API en verschillende DLL-functies breidt de functionaliteit van VB aanzienlijk uit en verbetert vaak de prestaties van programma's. De straf hiervoor is echter het risico van verminderde toepassingsbetrouwbaarheid, vooral tijdens het debuggen.

Een van de belangrijkste voordelen van de VB-omgeving is de betrouwbaarheid van het programma-ontwikkelingsproces: onder controle van de interpreter kan de programmacode in theorie het werk van Windows en VB zelf niet verstoren. De programmeur is misschien niet erg voorzichtig met het correct doorgeven van parameters aan de aangeroepen functies - dergelijke fouten zullen gemakkelijk door de interpreter zelf worden gedetecteerd, hetzij tijdens de vertaling van de code, hetzij tijdens de uitvoering ervan. In het meest onaangename geval wordt de verwerkingsmodus gewoon onderbroken, met een indicatie van waar en waarom de fout is opgetreden.

Door Windows API's of andere DLL's te gebruiken, wordt deze controle over gegevensoverdracht en code-uitvoering buiten de VB-omgeving direct verwijderd. Daarom kan een fout in de aanroep van externe functies leiden tot onbruikbaarheid van zowel VB als het besturingssysteem. Dit geldt met name in de fase van programmaontwikkeling, wanneer de aanwezigheid van fouten heel natuurlijk is. Dus, gebruikmakend van de bredere mogelijkheden van de functies van de basislaag van het systeem, neemt de programmeur de verantwoordelijkheid voor het juiste gebruik ervan.

Het probleem wordt verergerd door het feit dat verschillende programmeertalen verschillende manieren gebruiken om parameters tussen procedures door te geven. (Precies, er worden standaard verschillende overdrachtsmethoden gebruikt, omdat veel talen meerdere methoden kunnen ondersteunen.) De Win API's zijn geïmplementeerd in C / C ++ en gebruiken de conventies voor het doorgeven van parameters van dat systeem, die verschillen van de gebruikelijke VB versie.

In dit verband moet worden opgemerkt dat het verschijnen van analogen van API-functies die in VB zijn ingebouwd, juist wordt gerechtvaardigd door de aanpassing van de laatste aan de VB-syntaxis en de implementatie van het bijbehorende controlemechanisme voor gegevensuitwisseling. Merk ook op dat in het stadium van experimentele foutopsporing van de applicatie, bij het maken van een uitvoerbare module, het beter is om de P-code compilatieoptie te gebruiken in plaats van Native Code (machinecode). In het eerste geval zal het programma draaien onder de controle van de tolk - langzamer dan machinecode, maar betrouwbaarder vanuit het oogpunt van mogelijke foutieve impact op het besturingssysteem en een handiger modus bieden voor het identificeren van mogelijke fouten.

Tip 3: Dan Appleman's tien best practices voor robuuste API-programmering in VB

Het gebruik van een API-functie vereist meer zorgvuldige programmering met behulp van enkele niet zo bekende methoden voor het aanroepen van procedures (vergeleken met VB). Verder zullen we deze vragen voortdurend behandelen. En nu presenteren we een samenvatting van het advies over dit onderwerp geformuleerd door Dan Appleman (hun eerste versie verscheen in 1993) met enkele van onze toevoegingen en opmerkingen.

1. Onthoud ByVal. De meest voorkomende fout die wordt gemaakt bij het openen van API- en DLL-functies is het onjuiste gebruik van het ByVal-sleutelwoord: ze vergeten het te vermelden of, omgekeerd, plaatsen het wanneer het niet nodig is.

Deze voorbeelden tonen het effect van de ByVal-operator op het doorgeven van parameters

Er moet hier worden herinnerd dat parameters in elk programmeersysteem, inclusief VB, op twee manieren worden doorgegeven: door verwijzing (ByRef) of door waarde (ByVal). In het eerste geval wordt het adres van de variabele doorgegeven (deze optie wordt standaard gebruikt in VB), in het tweede geval - de waarde ervan. Het fundamentele verschil is dat door middel van een referentie de gewijzigde waarde van de doorgegeven parameter wordt teruggestuurd naar het aanroepende programma.

Voer een experiment uit met de volgende programma's om erachter te komen:

Dim v As Integer v = 2 Bel MyProc (v) MsgBox “v =“ & v Sub MyProc (v As Integer) v = v + 1 End Sub

Door dit voorbeeld uit te voeren, ontvangt u een bericht met de waarde van de variabele gelijk aan 3. Feit is dat in dit geval het adres van de variabele v, fysiek gemaakt in het aanroepende programma, wordt doorgegeven aan de MyProc-subroutine. Verander nu de beschrijving van de procedure in:

Sub MyProc (ByVal v As Integer)

Als gevolg hiervan ontvangt u bij het uitvoeren van de test v = 2, omdat alleen de oorspronkelijke waarde van de variabele aan de procedure wordt doorgegeven - het resultaat van de bewerkingen die ermee worden uitgevoerd, wordt niet teruggestuurd naar het aanroepende programma. De modus voor doorverbinden op waarde kan ook als volgt worden gewijzigd met behulp van de oproepoperator:

Sub MyProc (v As Integer) ... Bel MyProc ((v)) '(v) - haakjes geven overdracht op waarde _ modus aan.

Wanneer echter wordt verwezen naar interne VB-procedures, is het ByVal-sleutelwoord niet toegestaan ​​in de Call-instructie - in plaats daarvan worden haakjes gebruikt. Hier is een verklaring voor.

In het klassieke geval (C, Fortran, Pascal) hangt het verschil tussen ByRef en ByVal af van wat er precies op de gegevensuitwisselingsstack wordt geduwd - het adres van een variabele of de waarde ervan. In Basic wordt historisch gezien de ByVal-versie van software-emulatie gebruikt - het adres staat altijd op de stapel, maar alleen wanneer het wordt doorgegeven door waarde, wordt hiervoor een tijdelijke variabele gemaakt. Om deze twee opties (Classic en Basic) te onderscheiden, worden verschillende manieren gebruikt om de ByVal-modus te beschrijven. Merk op dat de emulatie van de ByVal-modus in VB een hogere programmabetrouwbaarheid biedt: door de vorm van de aanroep te verwarren, loopt de programmeur alleen het risico dat de gecorrigeerde waarde van de variabele wel (of niet) terugkeert naar het aanroepende programma. In de "klassieke" versie kan een dergelijke verwarring leiden tot een fatale fout tijdens de uitvoering van de procedure (bijvoorbeeld wanneer in plaats van een geheugenadres een variabele waarde gelijk aan bijvoorbeeld nul wordt gebruikt).

DLL-functies zijn geïmplementeerd volgens "klassieke" principes en vereisen daarom een ​​verplichte beschrijving van hoe gegevens worden uitgewisseld met elk van de argumenten. Het is voor dit doel dat functiedeclaraties via de Declare-beschrijving (meer precies, een lijst met doorgegeven argumenten) dienen. Meestal wordt het doorgeven van parameters aan een Windows API of DLL-functie gedaan met behulp van het ByVal-sleutelwoord. Bovendien kan het zowel in het Declare-statement als direct bij het aanroepen van de functie worden opgegeven.

De gevolgen van het onjuist doorgeven van parameters zijn eenvoudig te voorspellen. Als u een duidelijk ongeldig adres ontvangt, wordt u gevraagd om een ​​GPF-bericht (General Protection Fault). Als de functie een waarde krijgt die overeenkomt met een geldig adres, dan komt de API-functie in het gebied van iemand anders (bijvoorbeeld de Windows-kernel) met alle catastrofale gevolgen van dien.

2. Controleer het type van de doorgegeven parameters. Het juiste aantal en type doorgegeven parameters zijn even belangrijk. De argumenten die in de Declare zijn gedeclareerd, moeten overeenkomen met de verwachte parameters in de API-functie. De meest voorkomende fout bij het doorgeven van parameters houdt verband met het verschil tussen NULL en strings met een lengte van nul - onthoud dat ze niet hetzelfde zijn.

3. Controleer het retourtype.

VB is vrij tolerant ten aanzien van typemismatches in functieretourwaarden, aangezien numerieke waarden meestal via registers worden geretourneerd in plaats van via de stapel. De volgende regels helpen u bij het bepalen van de juiste waarde die wordt geretourneerd door een API-functie:

• Een DLL-functie die geen waarde retourneert (analoog aan void in 'C') moet worden gedeclareerd als een VB Sub.
• een API-functie die een geheel getal retourneert (Integer of Long) kan worden gedefinieerd als een Sub of een Functie die een waarde van het juiste type retourneert.
• geen van de API-functies retourneert drijvende-kommagetallen, maar sommige DLL's retourneren dit gegevenstype mogelijk.

4. Gebruik de "As Any"-constructie met grote zorg. Veel Windows API-functies hebben de mogelijkheid om parameters van verschillende typen te accepteren en de constructie As Any te gebruiken (het type wordt geïnterpreteerd afhankelijk van de waarde van andere doorgegeven parameters).

Een goede oplossing in dit geval zou zijn om meerdere functie-aliassen te gebruiken, waarbij twee of meer declaraties voor dezelfde functie worden gemaakt, waarbij elk van de beschrijvingen parameters van een specifiek type specificeert.

5. Vergeet niet de strings te initialiseren. Er zijn veel functies in de Win API die informatie retourneren door gegevens in stringbuffers te laden die als parameter zijn doorgegeven. In je programma lijkt het alsof je alles goed doet: vergeet ByVal niet, geef de parameters correct door aan de functie. Maar Windows kan niet controleren hoe groot het geheugen voor de string is. De lijngrootte moet groot genoeg zijn voor alle gegevens die erin kunnen worden geplaatst. Het is de verantwoordelijkheid van de VB-programmeur om een ​​buffer van de juiste grootte te reserveren.

Opgemerkt moet worden dat in 32-bits Windows, bij gebruik van strings, de conversie wordt uitgevoerd van Unicode (double-byte-codering) naar ANSI (single-byte) en vice versa, rekening houdend met de nationale instellingen van het systeem. Daarom is het soms handiger om byte-arrays te gebruiken in plaats van stringvariabelen om buffers te reserveren. (Hierover hieronder meer.)

Meestal kunt u met de Win API-functies zelf de maximale blokgrootte definiëren. In het bijzonder moet je soms hiervoor een andere API-functie aanroepen, die de blokgrootte zal "vragen". Met GetWindowTextLength kunt u bijvoorbeeld de grootte van de rij bepalen die nodig is voor de venstertitel, die wordt opgehaald door de functie GetWindowText. In dit geval zorgt Windows ervoor dat je niet naar het buitenland gaat.

6. Zorg ervoor dat u Option Explicit gebruikt.

7. Controleer de parameterwaarden en retourneer waarden zorgvuldig. VB heeft goede typecontrolemogelijkheden. Dit betekent dat wanneer u een ongeldige parameter probeert door te geven aan een VB-functie, het ergste dat kan gebeuren, is dat u een foutmelding krijgt van VB. Maar dit mechanisme werkt helaas niet bij toegang tot Windows API-functies.

Windows 9x heeft verbeterde parametervalidatie voor de meeste API-functies. Daarom veroorzaakt de aanwezigheid van een fout in de gegevens meestal geen fatale fout, maar het is niet zo eenvoudig om te bepalen wat de oorzaak is.

Hier kunt u verschillende manieren gebruiken om dit type fout te debuggen:

• gebruik de eenstaps-foutopsporingsmodus of de opdracht Debug.Print om elke verdachte API-aanroep te controleren. Controleer de resultaten van deze aanroepen om er zeker van te zijn dat alles binnen de normale limieten valt en dat de functie correct is voltooid;
• gebruik een Windows-foutopsporingsprogramma zoals CodeView en een Windows-foutopsporingsprogramma (beschikbaar in de Windows SDK). Deze tools kunnen parameterfouten detecteren en in ieder geval bepalen welke API-functie de fout veroorzaakt;
• gebruik aanvullende tools van derden om de soorten parameters en de geldigheid van hun waarden te controleren. Dergelijke tools kunnen niet alleen parameterfouten vinden, maar zelfs verwijzen naar de regel VB-code waar de fout is opgetreden.

Bovendien is het absoluut noodzakelijk om het resultaat van de API-functie te controleren.

8. Onthoud dat gehele getallen in VB en Windows niet hetzelfde zijn. Allereerst moet worden bedacht dat de term "Integer" in VB een 16-bits getal betekent, in de Win-documentatie 32 - 32-bit. Ten tweede zijn gehele getallen (Integer en Long) in VB getekende hoeveelheden (dat wil zeggen, één cijfer wordt gebruikt als teken, de rest wordt gebruikt als de mantisse van een getal), in Windows worden alleen niet-negatieve getallen gebruikt. Met deze omstandigheid moet rekening worden gehouden wanneer u de doorgegeven parameter vormt met behulp van rekenkundige bewerkingen (bijvoorbeeld het adres berekenen door een grondtal en een offset toe te voegen). De standaard rekenfuncties van VB zijn hiervoor niet geschikt. Hoe te zijn in dit geval, we zullen afzonderlijk praten.

9. Let goed op de namen van de functies. In tegenstelling tot Win16 zijn de namen van alle Win32 API-functies gevoelig voor het exacte gebruik van hoofdletters en kleine letters (wat niet het geval was in Win16). Gebruik je ergens een kleine letter in plaats van een hoofdletter of andersom, dan wordt de gewenste functie niet gevonden. Zorg er ook voor dat u het achtervoegsel A of W correct gebruikt in functies die stringparameters gebruiken. (Zie hieronder voor meer informatie hierover.)

10. Sla je werk vaker op. Fouten gerelateerd aan onjuist gebruik van DLL en Win API kunnen leiden tot een abnormale beëindiging van de VB-omgeving, en mogelijk het gehele besturingssysteem. U moet ervoor zorgen dat de code die u schrijft, is opgeslagen voordat u de test uitvoert. Het eenvoudigste is om de modus voor automatische opname van projectmodules in te stellen voordat het project in de VB-omgeving wordt gestart.

Na het lezen van de vorige tip, denk je misschien dat het gebruik van Win API-functies een riskante onderneming is. Tot op zekere hoogte is dit waar, maar alleen in vergelijking met de veilige programmering door VB zelf. Maar met hun vakkundige toepassing en kennis van mogelijke valkuilen is dit risico minimaal. Bovendien is het vaak gewoon onmogelijk om het gebruik van de Win API volledig te verlaten - ze zullen nog steeds nodig zijn voor elke serieuze ontwikkeling.

Bovendien noemden we eerder de valkuilen voor een brede klasse van DLL's. In het geval van de Win API is alles veel eenvoudiger, omdat de vorm van het aanroepen van deze functies hier duidelijk is verenigd. In dit geval moeten de volgende hoofdpunten in gedachten worden gehouden:

1. Win32 API-functies zijn slechts functies, dat wil zeggen procedures van het type Functie (er waren veel Subs in de Win16 API). Dit zijn allemaal functies van het type Long, dus hun beschrijvingen zijn in de volgende vorm geschreven: Declare Function name ... As Long 'het type van de functie _ is expliciet gedefinieerd

   Declareer Functienaam & 'functietype _ is gedefinieerd met een achtervoegsel'

   Een aanroep van een API-functie ziet er als volgt uit:

Resultaat & = ApiName & ([ Lijst met argumenten]

1. Meestal is de geretourneerde waarde van een functie een exit-code voor een bewerking. Bovendien betekent een waarde die niet nul is in dit geval een normale voltooiing, een waarde nul betekent een fout. Meestal (maar niet altijd) kunt u de aard van de fout verduidelijken door de functie GetLastError aan te roepen. De beschrijving van deze functie ziet er als volgt uit: Declare Function GetLastError & Lib “kernel32” ()

   AANDACHT! Wanneer u in VB werkt, is het beter om de eigenschap LastDLLError van het Err-object te gebruiken om de waarde van de gekwalificeerde foutcode te krijgen, omdat VB soms de GetLastError-functie reset tussen de API-aanroep en de voortzetting van de uitvoering van het programma.

   U kunt de code die wordt geretourneerd door GelLastError interpreteren met behulp van de constanten die zijn geschreven in het API32.TXT-bestand, met namen die beginnen met het achtervoegsel ERROR_.

   De meest voorkomende fouten hebben de volgende codes:

   • ERROR_INVALID_HANDLE = 6 & - ongeldige handle
   • ERROR_CALL_NOT_IMPLEMENTED = 120 & - roep in Windows 9x een functie aan die alleen beschikbaar is voor Windows NT
   • ERROR_INVALID_PARAMETER = 87 & - ongeldige parameterwaarde

   Veel functies retourneren echter de waarde van een gevraagde parameter (OpenFile retourneert bijvoorbeeld een bestandsdescriptorwaarde). In dergelijke gevallen wordt de fout geïdentificeerd door een andere speciale Return & value, meestal 0 of –1.

2. Win32-API's gebruiken strikt vaste manieren om de eenvoudigste gegevenstypen door te geven. a) ByVal ... Zo lang

   Lange variabelen doen ten minste 80% van het argument doorgeven. Merk op dat het argument altijd gevolgd door het ByVal-trefwoord, wat onder andere betekent dat er een eenrichtingsgegevensoverdracht plaatsvindt - van een VB-programma naar een API-functie.

   B) ByVal ... As String

   Dit type gegevensoverdracht komt ook vrij vaak voor, en ook met een argument altijd ByVal wordt toegepast. Wanneer de API-functie wordt aangeroepen, wordt het adres van de string op de stapel geschreven, dus in dit geval is tmogelijk. Er zijn verschillende valkuilen waarmee u rekening moet houden bij het werken met snaren.

   Ten eerste is het geheugen voor een tekenreeks gereserveerd in het aanroepende programma, dus als de API-functie tekenreeksen vult, moet u een tekenreeks van de vereiste grootte maken voordat u deze aanroept. De functie GetWindowsDirectory retourneert bijvoorbeeld het pad naar de Windows-map, die per definitie niet langer mag zijn dan 144 tekens. Dienovereenkomstig zou een aanroep van deze functie er ongeveer zo uit moeten zien:

   WinPath $ = Spatie $ (144) 'reserveer een string van _ 144 tekens Resultaat & = GetWindowsDirectory & (WinTath $, 144) _' vul de buffer 'Resultaat & - het werkelijke aantal tekens in de _ mapnaam WinPath $ = Links $ (WinPath, Resultaat &)

   Het tweede probleem is dat wanneer de API-functie wordt aangeroepen, de originele string wordt geconverteerd naar een interne representatie, en wanneer de functie wordt afgesloten, vice versa. Als deze operatie in de dagen van Win16 alleen bestond uit het toevoegen van een nulbyte aan het einde van een string, dan werd dit met de komst van Win32 aangevuld met de transformatie van de dubbelbyte Unicode-codering naar ANSI en vice versa. (Dit werd in detail besproken in het artikel "Kenmerken van het werken met stringvariabelen in VB", ComputerPress 10'99 en 01'2000). Voor nu, laten we er rekening mee houden dat het gebruik van de ByVal ... As String-constructie, je strings alleen kunt uitwisselen met karaktergegevens.

   B) ... Zoals elke

   Dit betekent dat een geheugenbufferadres op de stapel wordt geduwd, waarvan de inhoud bijvoorbeeld door de API-functie wordt geïnterpreteerd, afhankelijk van de waarde van andere argumenten. As Any kan echter alleen worden gebruikt in een Declare-instructie - voor een specifieke aanroep van een functie moet een specifieke variabele als argument worden gedefinieerd.

   D) ... Als UserDefinedType

   Dit ontwerp wordt ook vaak gebruikt wanneer het nodig is om gegevens (meestal in beide richtingen) met enige structuur uit te wisselen. In feite is deze constructie een soort concrete implementatie van de As Any transmissievorm, maar in dit geval is de functie geconfigureerd voor een vaste constructie.

   De vorm van de datastructuur wordt bepaald door een specifieke API-functie en het is de verantwoordelijkheid van de programmeur om deze correct te beschrijven en te reserveren in het aanroepende programma. Dit ontwerp altijd gebruikt door zonder woorden ByVal, dat wil zeggen, in dit geval wordt overdracht door verwijzing uitgevoerd - het adres van de variabele wordt naar de stapel geschreven.

Een voorbeeld van het aanroepen van een API-functie

Laten we het bovenstaande illustreren met een voorbeeld van het gebruik van twee handige functies voor het werken met bestanden - lopen en lread, die als volgt worden beschreven:

Declare Function lopen Lib "kernel32" _ Alias ​​​​"_lopen" (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) As Long Declare Function lread Lib "kernel32" _ Alias ​​​​"_lread" (_ ByVal hFile As Long, lpBuffer zoals elk, _ ByVal wBytes zo lang) zo lang

In VB zijn hun tegenhangers - in dit geval de exacte - de Open en Get-instructies (voor binaire modus). Laten we meteen letten op het gebruik van het Alias-trefwoord in een functiedeclaratie - dit is precies het geval wanneer u niet zonder kunt. Echte functienamen in de bibliotheek beginnen met een onderstrepingsteken (typische C-stijl), wat niet is toegestaan ​​in VB.

De bewerking voor het openen van een bestand kan er als volgt uitzien:

Const INVALID_HANDLE_VALUE = -1 'ongeldige _ descriptorwaarde lpFileName $ = "D: \ calc.bas"' bestandsnaam wReadWrite & = 2 'lees-schrijfmodus hFile & = lopen (lpFileName $, wReadWrite &) _' bestandsdescriptor definiëren If hFile & = INVALID_HANDLE_VALUE Dan _ 'bestandsopeningsfout' verduidelijk de foutcode CodeError & = Err.LastDllError 'CodeError & = GetLastError _' deze constructie werkt niet End If

Er zijn hier twee aandachtspunten:

• als de waarde van de functie krijgen we de waarde van de bestandsdescriptor. De fout komt overeen met de waarde –1;
• alleen in dit geval werkt de aanroep van de GetLastError-functie niet - om de opgegeven foutwaarde te krijgen, wendden we ons tot het Err-object (we spraken hierboven over de mogelijkheid van een dergelijke situatie).

U kunt dan de inhoud van het bestand lezen, maar dit veronderstelt dat de programmeur enig begrip van de structuur moet hebben (net zoals bij het werken met willekeurige binaire bestanden). In dit geval kan een aanroep van de lread-functie er als volgt uitzien:

Dim MyVar As Single wBytes = lread (hFile &, MyVar, Len (MyVar) 'read real number, 4 bytes' wBytes - aantal daadwerkelijk gelezen gegevens,' -1 - error ... Typ MyStruct x As Single i As Integer End Typ Dim MyVar As MyStruct wBytes = lread (hFile &, MyVar, Len (MyVar)) 'lees datastructuur, 6 bytes

Merk nogmaals op: het tweede functieargument wordt doorgegeven door verwijzing, de rest wordt doorgegeven door waarde.

Dim MyVar As String MyVar = Space $ (10) 'reserveer een variabele voor 10 tekens wBytes = lread (hFile &, ByVal MyVar, Len (MyVar))' lees een tekenreeks, 10 tekens

Hier ziet u een belangrijk verschil met het vorige voorbeeld - de stringvariabele gaat noodzakelijkerwijs vergezeld van het ByVal-sleutelwoord.

Het lezen van de inhoud van een bestand in een array (voor de eenvoud gebruiken we een eendimensionale bytearray) gaat als volgt:

Dim MyArray (1 tot 10) As Byte wBytes = lread (hFile &, MyArray (1), _ Len (MyArray (1)) * 10) 'lees 10 array-elementen

Door het eerste element van de array als argument op te geven, geven we het adres door van het begin van het geheugengebied dat voor de array is gereserveerd. Het is duidelijk dat elk fragment van de array op deze manier kan worden gevuld:

WBytes = lread (hFile &, MyArray (4), _ Len (MyArray (1)) * 5) ‘lees array-elementen 4 tot 8

Tip 5. Gebruik alias voor versnellingen en parameters Zoals elke

Hier zullen we, op basis van het vorige voorbeeld, de essentie van de vierde tip van Dan Appleman onthullen.

Wanneer u met de lread-functie werkt, onthoud dan dat wanneer u deze opent met behulp van een stringvariabele, u het ByVal-sleutelwoord moet gebruiken (anders kan het bericht over een illegale bewerking niet worden vermeden). Voor de zekerheid kunt u een extra speciale beschrijving van dezelfde functie maken om alleen met stringvariabelen te werken:

Declareer de functie lreadString Lib "kernel32" _ Alias ​​​​"_lread" (_ ByVal hFile zo lang, ByVal lpBuffer als string, _ ByVal wBytes zo lang) zo lang

Wanneer u met deze beschrijving werkt, hoeft u ByVal niet langer op te geven bij het openen van:

WBytes = lreadString (hFile &, MyVarString, _ Len (MyVarString)) '

Het lijkt erop dat je met de syntaxis van de Declare-instructie een vergelijkbare speciale beschrijving voor een array kunt maken:

Declareer functie lreadString Lib "kernel32" Alias ​​​​"_lread" (_ ByVal hFile zo lang, lpBuffer () als byte, _ ByVal wBytes zo lang) zo lang

Echter, het beroep

WBytes = lreadArray (hFile &, MyArray (), 10)

leidt onvermijdelijk tot een fatale programmafout.

Dit is een voortzetting van het gesprek over de eigenaardigheden van het verwerken van stringvariabelen in Visual Basic: VB gebruikt een dubbelbyte Unicode-codering, Win API - een enkelbyte ANSI (en met het formaat geaccepteerd in C - met een nulbyte aan de einde). Dienovereenkomstig wordt, wanneer stringvariabelen als argument worden gebruikt, de conversie van Unicode naar ANSI altijd automatisch uitgevoerd wanneer een API-functie (meer precies, een DLL-functie) wordt aangeroepen, en de omgekeerde conversie wordt uitgevoerd bij terugkeer.

De conclusie hiervan is eenvoudig: met String-variabelen kunt u tekengegevens uitwisselen, maar u kunt ze niet gebruiken om willekeurige binaire informatie uit te wisselen (zoals het geval was met 16-bits versies van VB). In het laatste geval is het beter om een ​​eendimensionale byte-array te gebruiken.

Zoals u weet, kan het type String worden gebruikt om een ​​aangepaste structuur te beschrijven. In dit verband moet het volgende worden onthouden:

• Het is absoluut onmogelijk om de volgende constructie te gebruiken om naar de Win API te verwijzen: Type MyStruct x As Single s As String 'variabele lengte string End Type

  In het geval van een string met variabele lengte wordt een stringdescriptor doorgegeven als onderdeel van de structuur met alle gevolgen van dien in de vorm van een uitvoeringsfout van het programma.

• U kunt een string met vaste lengte als structuurelement gebruiken: Type MyStruct x As Single s As String * 8 'string met vaste lengte End Type

In dit geval wordt de overeenkomstige conversie van coderingen uitgevoerd.

En de laatste opmerking: je kunt in geen geval een array van stringvariabelen (zowel vaste als variabele lengte) gebruiken bij het aanroepen van een API-functie. Anders wordt de schijn van een "illegale operatie" gegarandeerd.

Het is zeer waarschijnlijk dat u een situatie tegenkomt waarin u uw eigen DLL-functies moet schrijven. De noodzaak hiervan zal onvermijdelijk verschijnen als u gemengde programmeertechnologie gebruikt - het gebruik van twee of meer programmeertalen om één applicatie te implementeren.

Merk in dit verband op dat gemengd programmeren vrij gebruikelijk is voor een vrij complexe toepassing. Elke taal (meer precies, een op taal gebaseerd programmeersysteem) heeft zijn eigen sterke en zwakke punten, dus het is vrij logisch om de voordelen van verschillende tools te gebruiken om verschillende problemen op te lossen. Bijvoorbeeld VB - voor het maken van een gebruikersinterface, C - voor efficiënte toegang tot systeembronnen, Fortran - voor het implementeren van numerieke algoritmen.

De mening van de auteur is dat elke serieuze programmering vereist dat de ontwikkelaar ten minste twee tools bezit. Natuurlijk is het in de moderne omstandigheden van een duidelijke taakverdeling erg moeilijk om een ​​uitstekende expert te zijn, zelfs in twee systemen, dus het schema "hoofd- en hulptalen" is logischer. Het idee hier is dat zelfs een oppervlakkige kennis van de "hulptaal" (het schrijven van vrij eenvoudige procedures) de effectiviteit van de "hoofdtaal" aanzienlijk kan vergroten. Merk op dat kennis van VB, althans als een aanvullende, tegenwoordig een bijna verplichte vereiste is voor een professionele programmeur. Trouwens, in de dagen van DOS voor elke programmeur, inclusief Basic, was het zeer wenselijk om de basis van Assembler te kennen.

Op de een of andere manier, maar zelfs in de omstandigheden van groepswerk, wanneer elke programmeur zich bezighoudt met zijn eigen specifieke bedrijf, moeten alle projectdeelnemers een idee hebben van de kenmerken van de procedurele interface in verschillende talen. En om te weten dat veel programmeersystemen (inclusief VB), naast de standaardinterface, u toestaan ​​om andere, uitgebreide methoden te gebruiken om naar procedures te verwijzen, die het mogelijk maken om de interface aan te passen aan een andere taal.

Let bij het bestuderen van de interprocedurele interface op de volgende mogelijke valkuilen:

• Verschillende talen kunnen verschillende conventies gebruiken voor het schrijven van identifiers. Er wordt bijvoorbeeld vaak een onderstrepingsteken gebruikt aan het begin van een procedurenaam, wat verboden is in VB. Dit probleem is eenvoudig op te lossen door het Alias-trefwoord in het Declare-statement te gebruiken (zie voorbeeld tip 2.3).
• Een andere volgorde van het schrijven van de doorgegeven argumenten op de stapel kan worden gebruikt. In de dagen van DOS (ik weet eerlijk gezegd niet hoe het er nu uitziet in Windows), schreef C bijvoorbeeld de argumenten vanaf het einde van de lijst, andere talen (Fortran, Pascal, Basic) - vanaf het begin.
• Standaard worden verschillende principes voor het doorgeven van parameters gebruikt - op basis van referentie of op waarde.
• Verschillende principes voor het opslaan van stringvariabelen. In C (evenals in Fortran en Pascal) wordt de lengte van een string bijvoorbeeld gedefinieerd door een nulbyte aan het einde, terwijl in Basic de lengte expliciet wordt geschreven in de stringdescriptor. Natuurlijk moet u rekening houden met de mogelijkheid om verschillende tekencoderingen te gebruiken.
• Houd er bij het overzetten van multidimensionale arrays rekening mee dat er verschillende opties zijn om multidimensionale structuren om te zetten in eendimensionaal (beginnend vanaf de eerste index of vanaf de laatste, in relatie tot tweedimensionale arrays - "per rijen" of "per kolommen").

Rekening houdend met dit alles kunnen de volgende aanbevelingen worden geformuleerd:

• Gebruik de eenvoudigste, bewezen manieren om argumenten door te geven aan DLL-functies. De standaarden die zijn aangenomen voor de Win API zijn goede voorbeelden.
• Geef in geen geval arrays van stringvariabelen door.
• Gebruik heel voorzichtig het doorgeven van eenvoudige tekenreeksvariabelen en multidimensionale arrays.
• Zorg ervoor dat u speciaal de functionaliteit controleert van het mechanisme voor het doorgeven van argumenten van en naar de aangeroepen procedure. Schrijf een aangepaste test om de gegevensoverdracht te testen. Controleer afzonderlijk of elk argument correct is doorgegeven. Als je bijvoorbeeld een procedure hebt met meerdere argumenten, controleer dan eerst of elke parameter correct is doorgegeven voor een variant met één argument, en pas daarna voor de hele lijst.

Maar wat als de DLL-functie al is geschreven, bijvoorbeeld in Fortran, maar de invoerinterface niet goed aansluit bij de bovenstaande VB-standaarden? Er zijn hier twee tips te geven. Schrijf eerst een test-DLL-functie en probeer met vallen en opstaan ​​de juiste aanroep uit het VB-programma te vinden. Ten tweede: schrijf een adapterprocedure in dezelfde Fortran die een eenvoudige interface zou bieden tussen VB en een DLL-functie met het converteren van eenvoudige datastructuren naar complexe (bijvoorbeeld het converteren van een multidimensionale bytearray naar een stringarray).

Dus: gebruik DLL-functies. Maar blijf alert...

ComputerPers 9 "2000

Russische Win32 API-referentie