Introduksjon

Siste 10 år Windows– det mest populære (91,02 %) operativsystemet på PC-markedet. Windows-operativsystemer kjører på x86, AMD64, IA-64-plattformer. Det var også versjoner for DEC Alpha, MIPS og PowerPC.

Windows NT-familien:

Operativsystemer i denne familien kjørte på prosessorer med IA-32-arkitektur og noen RISC-prosessorer: Alpha, MIPS, Power PC (opp til versjon 2000, som bare ble utgitt i IA-32-versjonen). Windows NT er fullt 32-biters operativsystemer, og, i motsetning til versjon 1.0–3.x og 9x, krever ikke støtte fra MS-DOS.

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-biters utgave (2006) – Windows NT 5.2

Windows Server 2003 (2003) – Windows NT 5.2

Windows Vista (2006) – Windows NT 6.0

Windows Home Server (2007)

Windows Server 2008

Windows 7 (2009) – Windows NT 7.0 (gjeldende versjon – 6.1)

Grunnlaget Windows-familien NT er ment å dele adresserom mellom prosesser. Hver prosess har muligheten til å arbeide med minnet som er tildelt den. Den har imidlertid ikke tillatelse til å skrive til minnet til andre prosesser, drivere eller systemkode.

Windows NT-familien er et forebyggende multitasking-operativsystem i stedet for et sanntidsoperativsystem. Prosessortiden deles mellom tråder i henhold til "karusell"-prinsippet. Operativsystemkjernen tildeler en tidsdel (i Windows 2000 er kvantumet ca. 20 ms) til hver av trådene etter tur, forutsatt at alle trådene har samme prioritet. En tråd kan nekte tidsstykket som er tildelt den. I dette tilfellet avskjærer systemet kontrollen fra den (selv om den tildelte tidsdelen ikke er fullført) og overfører kontrollen til en annen tråd. Ved overføring av kontroll til en annen tråd lagrer systemet tilstanden til alle prosessorregistrene i en spesiell struktur i RAM. Denne strukturen kalles trådkonteksten. Lagring av trådens kontekst er tilstrekkelig for å gjenoppta driften senere.

API (Application Programming Interface) applikasjonsprogrammer) er et sett med funksjoner, vanligvis organisert som en DLL. API-funksjoner lar deg organisere et grensesnitt mellom et applikasjonsprogram og miljøet dette programmet kjører i. Å kalle API-funksjoner lar et program få tilgang til miljøressurser og kontrollere driften. Vanligvis definerer en API standarden for interaksjon mellom miljøet og applikasjonsprogrammet.

Win32 er navnet på et grensesnitt rettet mot 32-bits applikasjoner og implementert på så velkjente plattformer som Windows 95, Windows 98, Windows NT, Windows CE. Funksjonene som utgjør dette grensesnittet lar et applikasjonsprogram få tilgang til operativsystemressurser og kontrollere driften. Tidligere versjoner av Windows bruker et grensesnitt kjent som Win16. Selvfølgelig er ikke alle funksjonene som utgjør Win32-grensesnittet fullt implementert på alle plattformer, så å kalle den samme funksjonen under NT vil gi et spesifikt resultat, men under Windows 95 fungerer det som et stubkall. Enhver applikasjon som kjører i Windows-miljøet kaller direkte eller indirekte opp funksjoner som er inkludert i Win32 API.

Funksjonene som utgjør Win32-grensesnittet er organisert i flere dynamiske lenkebiblioteker (DLL-er) og kjørbare filer.

API-funksjoner er ikke nødvendigvis inkludert i Win32-grensesnittet. For eksempel består MAPI-grensesnittet (Messaging Application Programming Interface) av funksjoner designet for å behandle e-postmeldinger, TAPI (Telephone API) – funksjoner for arbeid med telefonmeldinger. MAPI, TAPI, samt Win32, er et visst sett med funksjoner som setter en viss interaksjonsstandard

Funksjonene som utgjør APIen er vanligvis organisert i form av DLL-er – dynamiske lenkebiblioteker. En av fordelene med en DLL er at uansett hvor mange applikasjoner (prosesser) som fungerer med funksjonene til samme DLL, finnes DLL-koden i en enkelt kopi.

1. Teoretisk del

1.1 Win32-funksjoner for å finne en liste over kjørende prosesser

programalgoritmebibliotekbruker

Win32 gir flere måter å liste kjørende prosesser på. Dessverre er det ingen enkelt metode som vil fungere på alle Win32-plattformer. Programmerere må kombinere flere metoder i ett program for å få det til å fungere på alle versjoner av Windows.

1. Vurder følgende metoder:

2. Bruke biblioteket Process Status Helper (PSAPI).

3. Bruke ToolHelp32 API

4. Bruke den udokumenterte ZwQuerySystemInformation-funksjonen

5. Gjennom ytelsetellere

6. Bruke grensesnitt for Windows Management Instrumentation

7. Socket grensesnitt funksjoner

1.2 Bruke biblioteket Prosessstatushjelper

Process Status Helper-biblioteket, også kjent som PSAPI, gir et sett med funksjoner som lar deg få informasjon om prosesser og enhetsdrivere. Biblioteket kommer inn del av Windows 2000/XP og er tilgjengelig som en installerbar komponent for Windows NT 4.0.

For å telle opp prosesser, tilbyr biblioteket EnumProcesses-funksjonen, som returnerer en rekke kjørende prosess-IDer. Nedenfor er teksten til EnumProcesses_PsApi-funksjonen, som implementerer prosessoppregning ved hjelp av PSAPI.

EnumProcesses-funksjonen lar deg ikke vite hvor mye plass som trengs for å akseptere hele utvalget av identifikatorer. Så vi kaller det i en løkke, og øker størrelsen på bufferen til størrelsen på den returnerte matrisen er mindre enn størrelsen på bufferen.

Siden vi ønsker å få prosessnavn i tillegg til prosessidentifikatorer, må vi gjøre det ekstra arbeid. For hver prosess får vi først håndtaket ved hjelp av OpenProcess-funksjonen og bruker deretter EnumProcessModules-funksjonen, som returnerer en liste over moduler som er lastet inn i prosessens adresserom. Den første modulen i listen er alltid modulen som tilsvarer programmets EXE-fil. Til slutt kaller vi GetModuleFileNameEx-funksjonen (som også er en del av PSAPI) for å hente banen til EXE-filen fra modulbeskrivelsen. Vi bruker navnet på EXE-filen uten banen som prosessnavn.

Vi må ta hensyn til spesialbehandling for to prosesser. Vi er tvunget til å håndtere separat systemprosessen (Idle) med ID 0, og systemprosessen (System), som har ID 2 på Windows NT 4 og 8 på Windows 2000/XP, fordi OpenProcess ikke tillater å åpne et håndtak for disse prosesser, returnerer feilkode ERROR_ACCESS_DENIED.

RTOS består av en kjerne, en prosessleder og utvidede tjenester på samme nivå som en kundeservice. Som et mikrokjerneoperativsystem implementerer QNX Neutrino RTOS de fleste grunnleggende tjenester i OS-kjernen, for eksempel varslingsoverføring, signaler, tidtakere, trådplanlegging og synkroniseringsfunksjoner. Og OS-tjenester, drivere og programmer er koblet sammen med prosesser.

Bestemmelsen er tilstrekkelig for løsningen av oppgaven fastsatt i de tekniske spesifikasjonene. 4. PROGRAMVAREIMPLEMENTERING AV PROBLEMET Programvareimplementering av applikasjonsstrukturen utviklet ovenfor består i å utvikle en kjørbar Win32-applikasjon i MS visuelle programmeringsmiljø Visuelt studio. Programvareprosjektet består av tre klasser - CFuzzyApp, CFuzzyDlg, CFuzzy_. I...

Utstedelse og aksept av lisenser). I forhold store nettverk Det anbefales å tildele lisenser for serveren separat datamaskin(eller flere - for reservasjon). 1.1 Arkitektur av terminalenheter I datateknologi forutsetter trelagsarkitektur, synonymt med trelags- eller flerlagsarkitektur, tilstedeværelsen av følgende applikasjonskomponenter: ...

tilgang, så går ikke eieren av serveren til politiet, men ansetter en hacker og "fyller gapet" i beskyttelsen. KAPITTEL 2. KRIMINELLE JURIDISKE KARAKTERISTIKKER AV FORBRYTELSER PÅ DATAINFORMASJONS-FELTEN 2.1. Ulovlig tilgang til datainformasjon Artikkel 272 i den russiske føderasjonens straffelov gir ansvar for ulovlig tilgang til datainformasjon beskyttet av loven, dvs. informasjon på...

Oversettelse: A. Nikolaev
S. Jusjtsjenko

Dan Hildebrand
Seniorarkitekt, FoU
QNX Software Systems Ltd.

Introduksjon

Den utbredte bruken av Windows 95 og Windows NT skapte et behov for innebygde sanntidsoperativsystemer som kunne romme kildekode skrevet for Win32 API. For tiden, som svar på dette, utvikler flere produsenter produkter som "omtrent" representerer sanntidsfunksjonene til Windows NT. Dessverre er Microsoft motvillige til å gi tilgang til Windows NT-kildekoden, og som et resultat kjører disse sanntidsutvidelsene utenfor operativsystemet. En slik implementering er å bygge inn "sanntidsutvidelser" direkte i laget som skiller NT fra maskinvaren ( NT maskinvareabstraksjonslag) eller HAL. Et annet tillegg kjører NT som en oppgave som kjører under sanntids OS, sammen med andre prosesser som kjører som separate oppgaver. Begge utvidelsene krever modifikasjoner av HAL, førstnevnte mer enn sistnevnte.

Men det er en annen, helt forskjellig fra den forrige, tilnærmingen til dette problemet. Den består av å implementere Win32 API på et OS som er spesielt designet for å fungere i sanntid, og dermed lar Win32-applikasjoner kjøre i sanntid sammen med native OS-applikasjoner. I denne artikkelen vil vi se på fordelene og ulempene ved disse alternativene.

Sanntid utført i HAL

HAL er det laveste programvarenivået som kobler Windows NT til maskinvaren. Den gir masom avbrudd, video, diskstasjoner osv. Ved å modifisere HAL kan kode legges til som avskjærer timeravbruddet og kjører, til en viss grad, i sanntid.

Siden maskinvareavbrudd primært håndteres av HAL og deretter overføres til operativsystemet, har HAL en førstehåndsfordel i forhold til OS. I stedet for umiddelbart å sende avbruddet, kan HAL bestemme seg for å bruke det til å kontrollere avsenderen inne i sanntidskjernen. Som svar på dette kan avsenderen kjøre et sett med HAL-residente oppgaver i sanntid. Siden avbruddene ikke har blitt fanget opp av sanntidskjernen, kan de sendes til NT for videre behandling, og NT-applikasjoner kan kjøre i henhold til CPU-sykluser som ikke lenger er opptatt av sanntidsoppgaver som kjører inne i HAL.

Problemet er at dette sanntidsarbeidet er "usynlig" for resten av systemet (bortsett fra CPU-syklusene som er tapt til sanntidskjernen og oppgavene som kjører inne i kjernen). HAL-residente sanntidsoppgaver kan nemlig ikke få direkte tilgang til hele tjenesten levert av Windows NT (GUI, diskstasjoner, nettverk, etc.). Som et resultat må utviklere som utfører denne metoden finne en måte å få HAL-residente oppgaver til å samvirke med NT-applikasjoner som kan ha full tilgang til hele tjenesten:

Fordeler og ulemper

Med den HAL-baserte metoden er Windows NT-miljøet bare litt modifisert, noe som betyr at operativsystemet er kompatibelt med enhetsdrivere og andre utvidelser. Men dette alternativet har flere ulemper:

Ingen kompatibilitet mellom standard- og sanntidsmiljøer

Poenget er at sanntidskjernen inne i HAL enten vil ha et veldig lite sett med Win32-funksjoner, eller et helt annet sett med verktøy. Som et resultat må prosesser som krever sanntidsutførelse programmeres på en helt annen måte enn konvensjonelle NT-programmer. Portering av kode mellom NT og HAL blir vanskelig.

Tilpasset utviklingsmiljø

På grunn av forskjellen i applikasjonsstruktur og kode, vil verktøyene for å utvikle og feilsøke sanntidsapplikasjoner også skille seg fra verktøyene for å lage vanlige søknader. Litt opplæring er nødvendig før du utvikler sanntidsproblemer.

Ustabilitet

Det tas for gitt at sanntidsoppgaver som kjører i HAL er svært ustabile. Mens NT-miljøet gir MMU-beskyttelse for vanlige oppgaver, kan feil i koden til HAL-residente sanntidsapplikasjoner lett føre til et fullstendig NT-krasj ("Blue Screen"). Som et resultat er utviklingsmiljøet ganske skjørt. I tillegg kan ikke sanntidsapplikasjoner som kjører i HAL tåle globale feil i NT selv.

Ekstra overhead

HAL-implementeringen beskrevet i pressen bruker en "avbruddspolling"-teknikk som opererer med en høy, konstant frekvens (20 000 Hz) for å håndtere sanntidsavbrudd. Dette avbruddet med fast frekvens forårsaker ekstra systemomfattende planleggingsoverhead ved å håndtere avbruddet når det ikke er nødvendig med arbeid i sanntid. Det øker også tiden det tar å begynne å fungere fordi sanntidshendelser ikke kan behandles før neste pollingintervall. En ekte sanntidskjerne er hendelsesdrevet, og reagerer umiddelbart på avbrudd i det øyeblikket de oppstår.

Store minnekrav

Bruk av HAL-utvidelsen øker bare NTs allerede store minnekrav. Som et resultat er denne løsningen fortsatt utilfredsstillende for mange minnebegrensede sanntidssystemer som kan dra nytte av et Win32-grensesnitt.

Sanntidsimplementering utenfor Windows NT

Det andre alternativet for å legge til sanntidsfunksjoner til Windows NT er å kjøre NT som den lavest prioriterte oppgaven under sanntidsoperativsystemet. Siden andre oppgaver kan kjøres med høyere prioritet enn NT, kan de suspendere NT-utførelse og oppnå bedre sanntidsdeterminisme. For større pålitelighet kjører disse oppgavene i et eget adresseområde fra NT:

Dessverre deler denne metoden mange av de største ulempene med HAL-utvidelsesmetoden beskrevet ovenfor. Utvikleren må som før jobbe med to helt forskjellige grensesnitt og velge mellom dem, avhengig av om han krever sanntidsdeterminisme eller ikke. Utviklingsverktøyene for disse applikasjonene er i stor grad forskjellige. Portering av kildekode mellom disse miljøene er svært vanskelig. Igjen, minnekravene for dette miljøet er betydelig høyere enn bare Windows NT.

Til tross for manglene ved begge metodene, har muligheten til å legge til noe sanntidsstøtte til standard Windows NT den positive siden - spesielt at kompatibiliteten med Windows NT i stor grad er bevart. Men fordi begge metodene legger til sine egne grensesnitt, undergraver de ånden i det sømløse "åpne system"-miljøet som har blitt nøye bygget de siste årene.

I stedet for å ta et OS (Windows NT) som ikke er hentet og prøve å legge til sanntidsfunksjoner til det, er det mye bedre å kjøre Win32-applikasjoner på et OS som er spesifikt bygget for sanntid. Et eksempel på en slik metode er implementeringen av Willows Win32-verktøysettet i miljøet til QNX®-operativsystemet, bygget på en mikrokjerne.

Legger til Win32 API til sanntids OS.

I et forsøk på å bringe inn i Win32-verdenen de samme fordelene som POSIX ga til UNIX-miljøet, godkjente European Computer Manufacturers Association (ECMA) Application Programming Interface for Windows for Windows eller APIW). Akkurat som POSIX-standardgruppene definerte POSIX utelukkende innenfor grensesnittet og ikke innenfor implementeringen, så definerte ECMA, sammen med OSF, APIW-standarden. Formålet med APIW er å definere en Win32-grensesnittstandard for utvikling i åpne systemer Programmer på tvers av plattformer som ikke nødvendigvis trenger å kjøre kun på Microsoft eller Intel-spesifikke operativsystemer.

QNX OS validerer denne "implementeringsuavhengige" metoden: det er et mikrokjernebasert operativsystem med høy ytelse som også støtter POSIX-standardgrensesnittet. I likhet med POSIX API, kan den ECMA-definerte APIW adopteres av QNX, slik at operativsystemet kan tilby en høyytelses sanntidsplattform for å kjøre applikasjoner skrevet for Win32 API. Denne tilnærmingen eliminerer mange av ulempene beskrevet for de to foregående metodene:

Bærekraftig miljø

QNX gir en kjøretidsmodell som er minst like robust som Windows NT, med prosesser som kjører i separate MMU-beskyttede adresserom. Som et resultat er sanntidsmiljøet som QNX gir for Win32-programmer mer rigid enn miljøet der HAL-residente oppgaver kjører uten minnebeskyttelse:

Kompatibilitet mellom standard- og sanntidsmiljøer

Sanntidsapplikasjoner kan skrives med full støtte Win32 API, inkludert GUI-tilgang. Dette er mye å foretrekke fremfor å ha bare et begrenset API inne i HAL eller et naturlig API administrert av OS som kjører NT som en oppgave. Utviklere trenger ikke å lære et nytt sett med funksjoner og utviklingsverktøy, og eksisterende Win32-kildekode kan umiddelbart kompileres og kjøres i et sanntidsmiljø.

Ingen overhead

QNX, som et hendelsesdrevet sanntids-OS, trenger ikke å polle for disse hendelsene. OS reagerer på maskinvareavbrudd bare når de oppstår, starter en avbruddsbehandler og distribuerer prosesser på minimal tid, som er typisk for et sanntids OS. Dette eliminerer unødvendige forsinkelser og ekstra ressurskostnader forbundet med polling i sanntid.

Kompakt plattform

Implementeringen av Win32 API i QNX betyr at runtime-miljøet er mer kompakt enn Windows 95, og mye mer kompakt enn Windows NT. Selv om det er kompakt, gir dette rammeverket robustheten til full minnebeskyttelse, i tillegg til sanntidsdeterminisme, støtte for Win32 API og POSIX API. Dette tilfredsstiller innebygde ROM- eller flash-systemer mye mer enn stasjonære operativsystemer Windows-type N.T.

Dette miljøet gir en ekstra fordel: på grunn av QNXs kompatibilitet med POSIX- og UNIX-standarder, kan kildekoden til UNIX-systemer også kompileres og kjøres. Portering av UNIX-kildekode til QNX-plattformen krever samme mengde kostnader som portering av kildekode mellom forskjellige versjoner av UNIX fra forskjellige leverandører. Som et resultat kan systemutviklere i sanntid enkelt portere kildekode fra både Win32- og UNIX-verdene direkte inn i deres sanntidsmiljø. Dette minimerer mengden kode som må skrives fra bunnen av og, enda viktigere, bidrar til å redusere tiden til markedet.

Implementering av Win32 API i QNX

For å implementere Win32 API i QNX OS, porterte Willows Software () og QNX Software Systems Willows RT-pakken til QNX og la til optimaliseringer for QNX for å få Willows-miljøet til å fungere bedre. Denne pakken fungerer som et plattformuavhengig grensesnitt mellom applikasjoner som kaller Win32 API og vertsoperativsystemet. Fra synspunkt av applikasjonsprogrammer, fungerer dette grensesnittet, implementert som et delt bibliotek, som Windows-operativmiljøet med alle dets muligheter og funksjoner som programmet forventer å se. Fra et utviklerperspektiv er det ikke nødvendig å mestre et nytt miljø for å rekompilere eksisterende Win32-applikasjoner.

Willows RT ble opprinnelig utviklet som Willows Toolkit for X Window System for Unix og for grafisk miljø Macintosh. Selv om det er en implementering av X Window for QNX, vil ikke kjøre Willows RT under X i et QNX-miljø tilfredsstille kompakthetskravene til det innebygde sanntidsmarkedet. Så, Willows RT har blitt portert til et mikrokjernebasert vindussystem - Photon microGUI ®, som kjører i QNX-miljøet (se Feil! Referansekilde ikke funnet. for flere detaljer). Photon kan utføre de samme funksjonene som X Window, men tar opp mindre minne (ca. 500Kb). Sammen med den lille størrelsen på selve QNX, åpner det for en ny løsning - Willows-on-QNX, som krever mye mer mindre minne enn Windows NT og lar Win32-applikasjoner kjøre i sanntid.

Willows API-komponenter

Willows API inkluderer 3 hovedkomponenter:

• Willows binært grensesnitt
• Willows bibliotek
• Willows Platform-abstraksjonslag

Willows binært grensesnitt

Win32-applikasjoner samhandler med Willows-biblioteket på samme måte som de gjør med Windows-miljøet: kaller opp API-funksjoner, mottar meldinger, laster ressurser og starter til og med andre Win32-applikasjoner. Eksisterende Win32-applikasjoner og dynamiske lenkebiblioteker (DLLer) for å få tilgang til Win32 API på ikke-Intel-plattformer samhandler med Willows binære grensesnitt. (Dette grensesnittet omdirigerer alle Windows API-forespørsler til Willows-biblioteket for å gjøre det mulig for utenlandske applikasjoner å oppnå native-lignende ytelse.) På samme måte samhandler Willows-biblioteket med driverområdet for å lage forespørsler om grafikk, vindu eller systemoperasjoner og akseptere svar eller asynkrone meldinger.

Willows API kan gjenkjenne 16-bits Intel-objekter som dynamiske lenkebiblioteker (DLL), Visual Basic-direktiver (VBX), drivere (DRV) og tilpassede verktøy kontroller produsert av "tredje selskaper". Derfor kan utviklere kombinere kildekode og binære moduler i et applikasjonsprogram. De kan også portere applikasjonene sine uten å vente på at noen tredjepart skal portere bibliotekene deres. Datafiler og grafikkfiler kan også brukes uten noen modifikasjoner, og programmer kan fortsette å laste inn data fra DLL-er uten noen modifikasjoner, noe som vil fremskynde produktets tid til markedet.

Virtuell maskin

Den virtuelle maskinen gir et maskinvareabstraksjonslag som simulerer driften av en Intel-prosessor i beskyttet modus. Dette laget administrerer kode- og datasegmenter, Intel-registre, avbruddsadministrasjon, instruksjoner og I/O-simulering. Alle kildeadresser er tilordnet adresser i segment-/offsetformat, inkludert dataadresser og Windows API-vindusfunksjonsadresser.

Portering av Willows RT til QNX, som har en innebygd Intel-prosessor, krever ikke slik maskinvaretilpasning. Som et resultat kan innfødt Wn32-kode kjøres med den nødvendige hastigheten, uavhengig av om Win32-kildekoden har blitt portert eller om miljøet til DLL-er som ingen kildekode er tilgjengelig for, har endret seg. Denne naturlige utførelsen bevarer programmenes evne til å oppnå sanntidsytelse på QNX OS.

DOS-emulator

DOS-emulatoren simulerer avbruddene og funksjonelle grensesnittet til DOS. Dette inkluderer alle DOS-funksjoner som brukes av Win32 API, inkludert prosesskontroll og I/O-operasjoner. Tilgang til parallell og serielle porter produsert ved å kartlegge funksjoner direkte til utdataenheter eller filtre.

QNX støtter tilgang til native DOS-medier, som Willows RT bruker til å lese og skrive filer til medier som harddisker og disketter. Som et resultat kan filer enkelt flyttes mellom QNX/Willows-systemer og det opprinnelige Windows/DOS-miljøet. Nettverkstilkoblinger via TCP/IP med SMB (eller CIFS) og NFS kan også brukes til deling nettverksfiler mellom QNX/Willows-systemer og Windows95 eller Windows NT.

16/32-bits forespørselsprosessor

16/32-bits forespørselsbehandler (16/32 Thunking Layer) manipulerer forespørsler mellom 16-bits Windows-kode og Willows-biblioteket. 16-biters koden fungerer i beskyttet modus, ved hjelp av en 16-bits stabel og et segment/offset for adressering. Hver forespørsel identifiseres av en "metode" som behandler den tilsvarende forespørselstypen. Denne metoden kan variere fra noe så enkelt som å spørre etter et bibliotek og returnere resultatet i visse registre, til mer komplekse operasjoner som transformerer adresser og datastrukturer både under samtalen og når prosedyren returnerer.

16/32-bit bootloader

16/32-bits Loader laster programmer, distribuerer programkode og data, dynamiske biblioteker og drivere. Lasteren fungerer sammen med den virtuelle maskinen og forespørselsbehandleren for å plassere segmenter med kode og data, inkludert manglende segmenter, som vil bli lastet inn senere ved applikasjonsforespørsler. Lasteren kobler også Willows-biblioteket til en DLL for å omdirigere anrop til biblioteket.

Willows bibliotek

For å implementere Microsoft Windows API ble Willows-biblioteket gjort plattformuavhengig, og skilte den plattformspesifikke koden fra selve biblioteket og plasserte den i en mer lavt nivå abstraksjon fra plattformen. For fullt ut å garantere plattformuavhengighet, ble biblioteket skrevet ved hjelp av selve Win32 API; dette har redusert antall funksjoner som må plasseres i plattformabstraksjonslaget til et minimum. Som et resultat forblir Willows-biblioteket kompatibelt med mange plattformer, og kompileres som naturlig kode for hver plattform for maksimal effektivitet.

Implementeringen av Willows-biblioteket er konsistent og kompatibel med kravene til APIW, introdusert av ECMA og OSF som et Windows API på tvers av plattformer. Den er skrevet i C og gir tilgang fra både C- og C++-programmer.

Alle de mest brukte Windows API-funksjonene, med unntak av spesifikke funksjoner for å starte binære programmer, er implementert i det binære grensesnittet. Det inkluderer alt standard funksjoner kontroller og klasser som type og meldingsklasser.

Biblioteket støtter:

• MDI-vinduer, generelle dialoger og dialogstyringsfunksjoner

• implementering av multitasking i én prosess

• utklippstavle og dynamisk datautveksling (DDE)

Biblioteket lagrer egenskapene til hvert vindu, og administrerer lokale og globale atomtabeller. Den har også tilgang til native og binære ressurser som dynamisk kan lastes og losses under kontroll av applikasjonsprogrammet.

Dette rammeverket legger også til et komplett sett med konfigurasjons- og feilsøkingsfunksjonalitet til Windows API. Ved å kjøre en feilsøkingsversjon av biblioteket, kan en applikasjon spore utførelsen av hver API og få diagnostisk informasjon om programmet mens det kjører. Debuggeren som er innebygd i biblioteket kan fungere uavhengig eller med konvensjonelle debuggere å få tak i detaljert informasjon i sanntid om tilstanden til programmet.

Abstraksjonslag av plattform

Dette laget inneholder all den plattformspesifikke koden for å lage og administrere vinduer, vise dem i disse vinduene og få tilgang til systemavhengige ressurser. Den inneholder tre undersystemer som er tilgjengelige gjennom samtaler til Willows-biblioteket:

Window Administrator Interface

Window Manager-grensesnittet lar biblioteket administrere - på en plattformuavhengig måte - alle vinduene som en applikasjon lager. Den kontrollerer funksjoner som å lage og slette vinduer, endre størrelse på og flytte vinduer, opprette og vedlikeholde vinduskontrollmenyer og angi titler og ikoner for minimerte vinduer.

All kommunikasjon med skrivebordsvindusbehandleren skjer med plattformspesifikk kode, som deretter videresender informasjon til den plattformuavhengige delen av vindusbehandleren. De fleste eksterne hendelser som Photon gir tilgang til fra grafikkprogrammer blir også fanget opp på dette nivået og konvertert til et standardsett med kommandoer som biblioteket kan behandle. Disse hendelsene inkluderer meldinger om oppretting, omtegning og sletting av vinduer, og meldinger om plassering og størrelse på vinduer.

Grensesnitt for grafisk enhet

Grensesnittet for grafikkenheten gir en måte å vise bilder direkte på vinduer eller skrivere. Den støtter grunnleggende grafikkoperasjoner som å tegne linjer, rektangler og ellipser, samt mer avanserte objektoperasjoner som penn, pensel, region og kunstverk. Den har også et komplett utvalg av tekstutdatafunksjoner, fra valg av font og farge til spesialeffekter som understreking og gjennomstreking. Willows Library and Graphics Device Interface støtter et bredt spekter av enheter, fra lavoppløselige, begrensede fargeskjermer til høyoppløselige flerfargeskjermer og et bredt utvalg av skrivere. Alle disse tjenestene kartlegges direkte til verktøyene som tilbys av Photon microGUI.

Systemtjenester grensesnitt

System Services Interface gir plattformspesifikk kode for tilgang til filsystemfasiliteter, minneallokering, nettverk og enhetstilgang. For eksempel overfører den alle nettverks- og kommunikasjonsforespørsler til de tilsvarende funksjonene som leveres av QNX-operativsystemet. Den støtter også inter-program communication (IPC) funksjoner som utklippstavle og DDE implementert i Willows-biblioteket. Den inneholder også plattformspesifikk kode assosiert med dynamiske biblioteker, slik at Willows Window Library kan støtte dynamisk lastet bibliotekssemantikk i QNX.

Forholdet mellom Win32-plattformer

Siden du enkelt kan portere Win32-applikasjoner mellom Windows og QNX, blir det relativt enkelt å lage distribuerte sanntidssystemer hvor hver node på nettverket kan kjøre det OS som passer best for brukerens behov, men hvor alle noder bruker det samme samme API og applikasjonskoder. Nå som et program bygget fra samme Win32-kildekode kan kjøres på forskjellige operativsystemer på samme lokale nettverk, blir det selvfølgelig viktig å sikre at disse distribuerte programmene er sammenkoblet. For å oppfylle dette kravet støtter QXN nettverk filsystemer SMB (CIFS) og NFS. Dessuten gir Photon microGUI deg muligheten til å vise og kontrollere QNX-nodeskjermen (eller et spesifikt programvindu) fra Windows-skjerm 95 eller Windows NT. Som et resultat, grafiske applikasjoner sanntid kan kjøres på harde sanntidsplattformer og vises på konvensjonelle nettverkstilkoblede systemer.

Ytterligere QNX-tjenester

Som et mikrokjernebasert sanntids-OS tilbyr QNX Win32-applikasjoner et sett med tjenester som ikke er tilgjengelige på Windows NT. Dette inkluderer robust sanntidsytelse, distribuert databehandling og et feiltolerant nettverk.

Distribuert prosessering, arvet fra QNX, lar deg bygge en applikasjon som en gruppe av interagerende prosesser. Uten å endre kildekoden kan disse prosessene distribueres over flere prosessorer og fortsette å kjøre som før. Dessuten kan prosessen bruke alle ressurser på en hvilken som helst QNX-node på det lokale nettverket, som om disse ressursene var på den lokale datamaskinen.

For å sikre maksimal nettverksytelse og robusthet, støtter QNX flere nettverkstilkoblinger for hver datamaskin på nettverket. QNX vil automatisk lastebalansere nettverkene, og hvis noen Nettverkstilkobling, omdirigere data over eksisterende nettverk.

Konklusjon

Tydeligvis tilbyr HAL-utvidelsen og kontroll-OS-teknikkene brukbare alternativer for å legge til sanntidsfunksjoner til NT, men til en pris. De tvinger utviklere til å jobbe med flere, hjemmelagde APIer og tilpassede utviklingsverktøy. De kjører sanntidsoppgaver i et relativt ustabilt miljø. I tillegg øker de minnekravene, som allerede er ganske store for NT.

På den annen side lar implementeringen av Win32 API på QNX sanntids OS utviklere bare bruke ett API - Win32. Dette gjør at sanntidsprosesser kan kjøres i et pålitelig, jevnt miljø. Og takket være QNXs lave krav til RAM, blir det mulig å bruke Win32 for små innebygde systemer.

Som et nøye utformet sanntids-OS optimert for bruk i feilkritiske applikasjoner, tilbyr QNX også utvikleren tilleggsfunksjoner som nettverksfeiltoleranse, distribuert prosessering og full kompatibilitet med POSIX og UNIX, som praktisk talt ikke er mulig i NT. Dessuten gjør QNX det relativt enkelt å kombinere Win32-plattformer, noe som gir utvikleren frihet til å velge riktig OS for hver oppgave. Til syvende og sist representerer utviklingen av Willows/QNX foreningen av "åpne systemer"-mentalitet og.

QNX og Photon microGUI er registrerte varemerker for QNX Software Systems.
Alle andre varemerker og registrerte varemerker tilhører sine respektive eiere.

Windows API - et sett med operativsystemfunksjoner

Forkortelsen API virker veldig mystisk og til og med skummelt for mange nybegynnere programmerere. Faktisk er et appli(API) bare noen ferdige sett med funksjoner som applikasjonsutviklere kan bruke. Generelt tilsvarer dette konseptet det som tidligere oftere ble kalt et subrutinebibliotek. Imidlertid refererer API vanligvis til en spesiell kategori av slike biblioteker.

Under utvikling, nesten alle kompleks applikasjon(MyApplication) for sluttbrukeren dannes et sett med spesifikke interne funksjoner som brukes til å implementere dette spesielle programmet, som kalles MyApplication API. Imidlertid viser det seg ofte at disse funksjonene effektivt kan brukes til å lage andre applikasjoner, inkludert av andre programmerere. I dette tilfellet må forfatterne, basert på strategien for å markedsføre produktet deres, avgjøre spørsmålet: åpner de tilgang til dette settet for eksterne brukere eller ikke? Hvis svaret er ja, vises uttrykket "Pakken inkluderer et åpent sett med API-funksjoner" i beskrivelsen av programvarepakken som en positiv egenskap (men noen ganger for ekstra penger).

Derfor refererer en API oftest til et sett med funksjoner som er en del av en applikasjon, men som også er tilgjengelig for bruk i andre programmer. For eksempel har Excel, i tillegg til sluttbrukergrensesnittet, et sett med Excel API-funksjoner som kan brukes, spesielt når du lager applikasjoner ved hjelp av VB.

Følgelig er Windows API et sett med funksjoner som er en del av selve operativsystemet og samtidig tilgjengelig for alle andre applikasjoner, inkludert de som er skrevet med VB. I denne forbindelse er analogien med BIOS/DOS-systemavbruddssettet, som faktisk er en DOS API, ganske berettiget.

Forskjellen er at utvalget av Windows API-funksjoner på den ene siden er mye bredere sammenlignet med DOS, og på den annen side inkluderer det ikke mange av verktøyene for direkte administrasjon av dataressurser som var tilgjengelige for programmerere i forrige OS. I tillegg utføres anrop til Windows API ved bruk av vanlige prosedyrekall, og kall til DOS-funksjoner utføres gjennom en spesiell prosessorinstruksjon kalt Interrupt.

Hvorfor trenger vi Win API for VB-programmerere?

Til tross for at VB har et stort utvalg av funksjoner, oppdages det i prosessen med mer eller mindre seriøs utvikling at deres evner ofte ikke er nok til å løse de nødvendige problemene. Samtidig begynner nybegynnerprogrammerere ofte å klage på manglene til VB og tenker på å endre verktøy, uten å mistenke at datamaskinen deres har et stort sett med verktøy, og de trenger bare å vite hvordan de skal bruke dem.

Når du blir kjent med Win API, oppdages det at mange innebygde VB-funksjoner ikke er noe mer enn kall til de tilsvarende systemprosedyrene, men bare implementert i form av syntaksen til et gitt språk. Når dette tas i betraktning, bestemmes behovet for å bruke API av følgende alternativer:

1. API-funksjoner som er fullt implementert som innebygde VB-funksjoner. Likevel, noen ganger i dette tilfellet er det nyttig å bytte til å bruke API, siden dette noen ganger kan forbedre ytelsen betydelig (spesielt på grunn av fraværet av unødvendige transformasjoner av beståtte parametere).
2. Innebygde VB-funksjoner implementerer bare et spesialtilfelle av den tilsvarende API-funksjonen. Dette er et ganske vanlig alternativ. For eksempel har CreateDirectory API-funksjonen flere muligheter enn den innebygde VB MkDir-operatøren.
3. Et stort antall API-funksjoner har ingen analoger i det hele tatt i den nåværende versjonen av VB-språket. Du kan for eksempel ikke slette en katalog ved hjelp av VB - for å gjøre dette må du bruke funksjonen DeleteDirectory.

Det bør også understrekes at noen API-funksjoner (deres andel i Win API er svært liten) ikke kan kalles fra VB-programmer på grunn av en rekke språkbegrensninger, for eksempel på grunn av manglende evne til å arbeide med minneadresser. Men i noen tilfeller kan ikke-trivielle programmeringsteknikker hjelpe (spesielt når det gjelder de samme adressene).

Forfatterens personlige synspunkt er at i stedet for å utvide de innebygde funksjonene fra versjon til versjon, burde VB vært gitt god beskrivelse de mest populære API-funksjonene. Samtidig vil jeg råde utviklere til ikke å vente på at en ny versjon av verktøyet med utvidede funksjoner skal vises, men å se nærmere på sammensetningen av det eksisterende Win API - det er sannsynlig at mulighetene du trenger kunne vært implementert allerede i versjon VB 1.0, utgitt i 1991.

Hvordan lære Win API

Dette er ikke et så enkelt spørsmål, med tanke på at antallet Win32 API-funksjoner er estimert til rundt 10 tusen (ingen vet det nøyaktige tallet, ikke engang Microsoft).

VB (versjon 4-6) inkluderer en fil som beskriver Win API-deklarasjoner - WIN32API.TXT (vi vil fortelle deg mer om bruken senere). Men for det første, med dens hjelp kan du få informasjon om formålet med en bestemt funksjon og dens parametere bare ved hjelp av de mnemoniske navnene som brukes, og for det andre er listen over funksjoner i denne filen langt fra fullstendig. På et tidspunkt (for syv år siden) hadde VB 3.0 spesielle hjelpefiler som beskrev funksjonene til Win16 API. Men allerede i v.4.0 forsvant denne nyttige informasjonen med et praktisk grensesnitt.

Omfattende informasjon om Win32 API finner du i hjelpen for Platform Software Development Kit, som er inkludert i MSDN Library CDene som følger med VB 5.0 og 6.0 Enterprise Edition og Office 2000 Developer Edition. Det er imidlertid ikke lett å finne den nødvendige informasjonen der og forstå den. For ikke å snakke om at alle beskrivelsene der er gitt i forhold til C-språket.

Bøkene til den berømte amerikanske eksperten Daniel Appleman er generelt anerkjent i verden for å lære API-programmering i VB-miljøet. Hans serie Dan Applemans Visual Basic Programmer's Guide to Vinduene API (for Win16, Win32, i forhold til forskjellige versjoner av VB) siden 1993 har vært konsekvent blant bestselgerne for VB-programmerere. Boken Dan Applemans VB 5.0 Programmer’s Guide to the Win32 API, utgitt i 1997, ble brakt til forfatteren fra USA av en venn som fant den i den første bokhandelen i en liten provinsby.

Denne boken er over 1500 sider lang, og dekker generelle API-programmeringsteknikker i VB, samt over 900 funksjoner. Den medfølgende CD-en inneholder hele bokens tekst og alle programeksempler, samt flere tilleggskapitler som ikke er inkludert i den trykte versjonen. I 1999 ga Dan Appleman ut en ny bok, Dan Applemans Win32 API Puzzle Book and Tutorial for Visual Basic Programmers, som inneholder informasjon om ytterligere 7600 funksjoner (men ikke så omfattende).

Win API og Dynamic Link Library (DLL)

Win API-settet er implementert i form av dynamiske DLL-er. Deretter vil vi faktisk snakke om teknologien for å bruke DLL-er i VB-miljøet ved å bruke eksemplet med biblioteker inkludert i Win API. Men når du snakker om DLL-er, er det noen viktige poeng å gjøre.

I dette tilfellet mener vi med DLL den tradisjonelle versjonen av binære dynamiske biblioteker, som gir applikasjoner direkte tilgang til de nødvendige prosedyrene - subrutiner eller funksjoner (på omtrent samme måte som det som skjer når man kaller prosedyrer inne i et VB-prosjekt). Slike biblioteker kan opprettes ved hjelp av forskjellige verktøy: VC++, Delphi, Fortran, bortsett fra VB (la oss se hva som vises i versjon 7.0) - sistnevnte kan bare lage ActiveX DLL-er, tilgjengelig via OLE Automation-grensesnittet.

Vanligvis har dynamiske bibliotekfiler filtypen .DLL, men dette er slett ikke nødvendig (for Win16 ble filtypen .EXE ofte brukt); eksterne enhetsdrivere er utpekt ved hjelp av .DRV.

Som vi allerede har nevnt, er det ganske vanskelig å bestemme det nøyaktige antallet Windows API-funksjoner og filene som inneholder dem, men de er alle plassert i systemkatalogen. I denne forbindelse er det bedre å fremheve sammensetningen av bibliotekene som er inkludert i operativsystemkjernen og hovedbibliotekene med viktige tilleggsfunksjoner.

Og nå noen tips.

Tips 1. Sørg for at DL-annonsen din er riktig formatert L-prosedyrer

Selve kallet til DLL-prosedyrer i et program ser nøyaktig det samme ut som i "vanlige" Visual Basic-prosedyrer, for eksempel:

Ring DllName([argumentliste])

For å bruke eksterne DLL-funksjoner (inkludert Win API), må de imidlertid deklareres i programmet ved å bruke Declare-setningen, som ser slik ut:

Erklær Sub LibProcedureName _ "LibraryName" _ [([ArgumentList])]

Erklær funksjon Funksjonsnavn _ Lib “LibraryName” _ [([ArgumentList])]

Her er valgfrie elementer av operatøren gitt i firkantede parenteser, i kursiv variable uttrykk, de resterende ordene er nøkkelen. Hjelpesystemet gir en ganske god beskrivelse av syntaksen til operatøren, så foreløpig vil vi bare notere noen få punkter.

Erklæringer om eksterne funksjoner skal plasseres i delen Generelle erklæringer i modulen. Hvis du plasserer det i en skjemamodul, må du spesifisere det private nøkkelordet (denne erklæringen vil kun være tilgjengelig i denne modulen) - dette er en begrensning for alle prosedyrer for skjemamoduler.

Win32 API-settet implementeres kun i form av funksjoner (Win16 API hadde mange underrutiner). For det meste er dette funksjoner Lang type, som oftest returnerer fullføringskoden for operasjonen.

Declare-operatøren dukket opp i MS Basic tilbake i DOS-dagene, og den ble også brukt til å deklarere interne prosjektprosedyrer. I Visual Basic er dette ikke nødvendig, siden erklæringen av interne prosedyrer automatisk er deres under- eller funksjonserklæring. Sammenlignet med Basic/DOS må den nye beskrivelsen angi navnet på bibliotekfilen der den nødvendige prosedyren er plassert. Wip API-biblioteker er plassert i Windows-systemkatalogen, så det er nok å oppgi bare filnavnet. Hvis du får tilgang til en DLL som er plassert på en vilkårlig plassering, må du skrive full vei til denne filen.

Beskrivelsen av Declare-setningen tar vanligvis ganske mye plass og passer ikke på én linje i kodevinduet. Derfor anbefaler vi at du følger en spesifikk linjebrytende ordning når du skriver søknader, for eksempel:

Erklær funksjon GetTempPath _ Lib “kernel32” Alias ​​​​“GetTempPathA” _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) As Long

I dette tilfellet er alle hovedelementene i beskrivelsen plassert på forskjellige linjer og er derfor enkle å lese.

Tips 2: Vær spesielt forsiktig når du arbeider med DLL-funksjoner

Bruken av Win API og ulike DLL-funksjoner utvider funksjonaliteten til VB betydelig og forbedrer ofte programytelsen. Prisen å betale for dette er imidlertid risikoen for å redusere påliteligheten til applikasjonen, spesielt under feilsøkingen.

En av de viktigste fordelene med VB-miljøet er påliteligheten til programutviklingsprosessen: opererer under kontroll av en tolk, kan programkoden teoretisk sett ikke brytes Windows-drift og VB selv. Programmereren er kanskje ikke veldig forsiktig med riktigheten av å sende parametere til kalte funksjoner - lignende feil vil lett bli oppdaget av tolken selv, enten under kodeoversettelse eller under utførelse. I det mest ubehagelige tilfellet vil behandlingsmodusen ganske enkelt bli avbrutt, med en indikasjon på hvor og hvorfor feilen oppsto.

Bruk av Windows API-funksjoner eller andre DLL-er fjerner direkte slik kontroll over overføringen av data og prosessen med kodekjøring utenfor VB-miljøet. Derfor kan en feil ved tilgang til eksterne funksjoner føre til at både VB og operativsystemet ikke fungerer. Dette gjelder spesielt på stadiet av programutvikling, når tilstedeværelsen av feil er ganske naturlig. Ved å bruke de bredere egenskapene til funksjonene til basislaget til systemet, tar programmereren derfor ansvar for riktig bruk av dem.

Problemet forverres ytterligere av det faktum at forskjellige programmeringsspråk bruker forskjellige måter å overføre parametere mellom prosedyrer. (Mer presist, forskjellige måter passing er standard, siden mange språk kan støtte flere metoder.) Win APIene er implementert i C/C++ og bruker systemets konvensjoner for parameteroverføring, som skiller seg fra den vanlige VB-versjonen.

I denne forbindelse bør det bemerkes at utseendet til analoger av API-funksjoner innebygd i VB er rettferdiggjort nettopp av tilpasningen av sistnevnte til VB-syntaksen og implementeringen av en passende. La oss også merke oss at på stadiet med eksperimentell feilsøking av applikasjonen når du oppretter en kjørbar modul, er det bedre å bruke P-kode kompileringsalternativet i stedet for Native Code (maskinkode). I det første tilfellet vil programmet kjøre under kontroll av en tolk - tregere sammenlignet med maskinkode, men mer pålitelig med tanke på mulig feilaktig innvirkning på operativsystemet og gir en mer praktisk modus for å identifisere mulige feil.

Tips 3: Dan Applemans ti tips for robust API-programmering i VB

Bruk av API-funksjonen krever mer forsiktig programmering ved å bruke noen mindre kjente prosedyrekallsteknikker (sammenlignet med VB). Vi vil fortsette å ta opp disse problemene i det følgende. Og nå presenterer vi et sammendrag av rådene formulert av Dan Appleman om dette emnet (deres første versjon dukket opp tilbake i 1993) med noen av våre tillegg og kommentarer.

1. Husk ByVal. Den vanligste feilen som gjøres ved tilgang til API- og DLL-funksjoner er feil bruk av ByVal-nøkkelordet: de glemmer enten å sette det, eller omvendt, legger det når det ikke er nødvendig.

Disse eksemplene viser virkningen av ByVal-operatøren på parameteroverføring

Det bør huskes her at overføring av parametere i et hvilket som helst programmeringssystem, inkludert VB, utføres på to hovedmåter: ved referanse (ByRef) eller ved verdi (ByVal). I det første tilfellet sendes adressen til variabelen (dette alternativet brukes som standard i VB), i det andre - verdien. Den grunnleggende forskjellen er at ved å bruke en referanse, returneres den endrede verdien til den beståtte parameteren til det anropende programmet.

For å forstå dette, utfør et eksperiment med følgende programmer:

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

Når du kjører dette eksemplet, vil du motta en melding med variabelverdien lik 3. Faktum er at i dette tilfellet sendes adressen til variabelen v, fysisk opprettet i det anropende programmet, til MyProc-subrutinen. Endre nå prosedyrebeskrivelsen til

Sub MyProc (ByVal v As Integer)

Som et resultat, når du utfører testen, vil du få v = 2, fordi bare startverdien til variabelen sendes til prosedyren - resultatet av operasjoner utført med den returneres ikke til det anropende programmet. Overføringsmodus etter verdi kan også endres ved hjelp av Ring operatør på følgende måte:

Sub MyProc (v As Integer) ... Call MyProc((v)) ' (v) - parenteser indikerer overføringsmodusen ved verdi.

Men når du får tilgang til interne VB-prosedyrer, er bruk av ByVal-nøkkelordet i Call-erklæringen forbudt - i stedet, runde parenteser. Det er en forklaring på dette.

I det klassiske tilfellet (C, Fortran, Pascal) avhenger forskjellen mellom ByRef- og ByVal-modusene av nøyaktig hva som er plassert på datautvekslingsstakken - adressen til variabelen eller dens verdi. Basic bruker historisk en variant av ByVal-programvareemulering - det er alltid en adresse på stabelen, men bare når man passerer ved verdi opprettes en midlertidig variabel for dette. For å skille mellom disse to alternativene (Classic og Basic), brukes forskjellige måter å beskrive ByVal-modus på. Merk at emulering av ByVal-modus i VB gir høyere programpålitelighet: ved å blande sammen referanseformen risikerer programmereren bare at den korrigerte verdien av variabelen vil bli returnert (eller ikke returnert) til det kallende programmet. I den "klassiske" versjonen kan slik forvirring føre til en fatal feil ved utføring av en prosedyre (for eksempel når en variabelverdi lik, for eksempel null, brukes i stedet for en minneadresse).

DLL-funksjoner implementeres i henhold til "klassiske" prinsipper og krever derfor en obligatorisk beskrivelse av hvordan data utveksles med hvert av argumentene. Funksjonserklæringer gjennom Declare-beskrivelsen (mer presist, listen over beståtte argumenter) tjener dette formålet. Den vanligste måten å sende parametere til en Windows API-funksjon eller DLL på er å bruke nøkkelordet ByVal. Dessuten kan det spesifiseres både i Declare-operatøren og direkte når du kaller opp funksjonen.

Konsekvensene av feil parameteroverføring er enkle å forutsi. Hvis du mottar en åpenbart ugyldig adresse, vil du motta en GPF-melding (General Protection Fault). Hvis funksjonen mottar en verdi som samsvarer med en gyldig adresse, vil API-funksjonen gå inn i et fremmed område (for eksempel Windows-kjernen) med alle de påfølgende katastrofale konsekvensene.

2. Sjekk hvilken type parametere som sendes. Riktig antall og type parametere som sendes er like viktige. Det er nødvendig at argumentene deklarert i Declare samsvarer med de forventede parameterne i API-funksjonen. Det vanligste tilfellet av feil ved parameteroverføring involverer forskjellen mellom NULL og en null-lengde streng - husk at disse ikke er det samme.

3. Sjekk returtypen.

VB er ganske tolerant for funksjonsreturtypefeil, siden numeriske verdier vanligvis returneres gjennom registre i stedet for stabelen. Følgende regler vil hjelpe med å bestemme riktig verdi returnert av en API-funksjon:

• En DLL-funksjon som ikke returnerer en verdi (analog med void i 'C') må deklareres som en VB Sub.
• En API-funksjon som returnerer en heltallsverdi (heltall eller lang) kan defineres som enten en Sub eller en funksjon som returnerer en verdi av den aktuelle typen.
• Ingen av API-funksjonene returnerer flyttall, men noen DLL-er kan godt returnere denne typen data.

4. Bruk "As Any"-konstruksjonen med stor forsiktighet. Mange Windows API-funksjoner har muligheten til å akseptere parametere forskjellige typer og bruk As Any-konstruksjonen (typetolkning utføres avhengig av verdien av andre beståtte parametere).

En god løsning i dette tilfellet kan være å bruke flere aliaser (Alias) av en funksjon ved å lage to eller flere deklarasjoner for samme funksjon, hvor hver deklarasjon spesifiserer parametere av en bestemt type.

5. Ikke glem å initialisere strengene. Det er mange funksjoner i Win API som returnerer informasjon ved å laste data inn i strengbuffere som sendes som en parameter. I programmet ditt kan du tilsynelatende gjøre alt riktig: ikke glem ByVal, send parametere til funksjonen riktig. Men Windows kan ikke sjekke hvor stor størrelsen på minnet som er tildelt for en rad er. Radstørrelsen må være stor nok til å romme alle dataene som kan plasseres i den. Ansvar for bufferreservasjon riktig størrelse ligger hos VB-programmereren.

Det skal bemerkes at i 32-biters Windows, når du bruker strenger, utføres konvertering fra Unicode (dobbeltbyte-koding) til ANSI (enkeltbyte-koding) og tilbake, under hensyntagen til de nasjonale systeminnstillingene. Derfor, for å reservere buffere, er det noen ganger mer praktisk å bruke byte-matriser i stedet for strengvariabler. (Mer om dette nedenfor.)

Oftest lar Win API-funksjoner deg definere maksimal blokkstørrelse selv. Spesielt krever dette noen ganger å kalle en annen API-funksjon som vil "fortelle" blokkstørrelsen. For eksempel lar GetWindowTextLength deg bestemme lengden på linjen som trengs for å holde vindustittelen som returneres av GetWindowText-funksjonen. I dette tilfellet sørger Windows for at du ikke drar til utlandet.

6. Pass på å bruke Option Explicit.

7. Sjekk parameterverdier og returverdier nøye. VB har gode typekontrollfunksjoner. Dette betyr at når du prøver å sende en ugyldig parameter til en VB-funksjon, er det verste som kan skje at du får en feilmelding fra VB. Men denne mekanismen fungerer dessverre ikke når du får tilgang til Windows API-funksjoner.

Windows 9x har forbedret parametersjekking for de fleste API-funksjoner. Derfor forårsaker tilstedeværelsen av en feil i dataene vanligvis ikke en fatal feil, men det er ikke så lett å bestemme hva som forårsaket det.

Her anbefaler vi å bruke flere måter å feilsøke denne typen feil på:

• Bruk trinn-for-trinn feilsøkingsmodus eller kommandoen Debug.Print for å sjekke hvert mistenkelige API-funksjonskall. Sjekk resultatene av disse samtalene for å sikre at alt er normalt og at funksjonen er fullført riktig;
• bruk en Windows debugger som CodeView og en debug versjon av Windows (tilgjengelig i Windows SDK). Disse verktøyene kan oppdage en parameterfeil og i det minste bestemme hvilken API-funksjon som forårsaker feilen;
• Bruk ekstra tredjepartsverktøy for å sjekke parametertyper og gyldigheten av deres verdier. Slike verktøy kan ikke bare finne parameterfeil, men også peke på linjen med VB-kode der feilen oppstod.

I tillegg er det nødvendig å sjekke resultatet av å utføre API-funksjonen.

8. Husk at heltall i VB og i Windows ikke er det samme. Først av alt, bør du huske på at begrepet "heltall" i VB betyr et 16-bits tall, mens det i Win 32-dokumentasjonen betyr et 32-bits tall. For det andre er heltall (heltall og langt) i VB fortegnsmengder (det vil si at ett siffer brukes som tegnet, resten som mantissen til tallet), i Windows brukes bare ikke-negative tall. Denne omstendigheten må huskes når du danner den beståtte parameteren ved hjelp av aritmetiske operasjoner(beregn for eksempel adressen ved å summere litt base og offset). Standard VB aritmetiske funksjoner er ikke egnet for dette. Vi vil diskutere hva du skal gjøre i dette tilfellet separat.

9. Vær nøye med funksjonsnavn. I motsetning til Win16, er navnene på alle Win32 API-funksjoner sensitive for nøyaktig bruk av små og store bokstaver (dette var ikke tilfelle i Win16). Hvis du et sted bruker en liten bokstav i stedet for en stor bokstav eller omvendt, vil den ønskede funksjonen ikke bli funnet. Vær også forsiktig med å bruke A- eller W-suffikset riktig i funksjoner som bruker strengparametere. (For mer om dette, se nedenfor.)

10. Lagre arbeidet ditt ofte. Feil knyttet til feil bruk av DLL-er og Win API-er kan føre til en nødavslutning av VB-miljøet, og muligens hele operativsystemet. Du bør sørge for at koden du skriver er lagret før testkjøringen. Det enkleste er å stille inn modus for automatisk opptak av prosjektmoduler før du starter prosjektet i VB-miljøet.

Etter å ha lest det forrige rådet, tror du kanskje at bruk av Win API-funksjoner er risikabelt. Til en viss grad er dette sant, men bare i sammenligning med den sikre programmeringen som VB selv tilbyr. Men med sin dyktige bruk og kunnskap om ev fallgruver denne risikoen er minimal. I tillegg er det ofte ganske enkelt umulig å helt forlate bruken av Win API - de vil fortsatt være nødvendige for enhver seriøs utvikling.

I tillegg har vi tidligere nevnt fallgruvene for en bred klasse DLL-er. Når det gjelder Win API, er alt mye enklere, siden skjemaet for tilgang til disse funksjonene er tydelig enhetlig. Følgende hovedpunkter bør huskes:

1. Win32 API-funksjoner er nettopp det: funksjoner, det vil si prosedyrer av funksjonstypen (det var mange underrutiner i Win16 API). Alle disse er funksjoner av typen Long, så beskrivelsene deres er skrevet i følgende form: Deklarer funksjonsnavn ... Så lenge 'funksjonstype _ er definert eksplisitt

   Deklarer funksjonsnavn og ' funksjonstype _ bestemmes ved hjelp av suffikset

   Anropet til API-funksjonen ser slik ut:

Result& = ApiName& ([ Argumentliste]

1. Oftest er returverdien til en funksjon fullføringskoden for operasjonen. Dessuten betyr en verdi som ikke er null i dette tilfellet normal fullføring, null betyr en feil. Vanligvis (men ikke alltid) kan du avklare arten av feilen ved å kalle opp GetLastError-funksjonen. Beskrivelsen av denne funksjonen ser slik ut: Erklær funksjon GetLastError& Lib “kernel32” ()

   MERK FØLGENDE! Når du arbeider i VB, er det bedre å bruke LastDLLError-egenskapen til Err-objektet for å få verdien av den kvalifiserte feilkoden, siden VB noen ganger tilbakestiller GetLastError-funksjonen mellom å kalle API og fortsette å kjøre programmet.

   Du kan tolke koden som returneres av GelLastError ved å bruke konstanter skrevet i API32.TXT-filen, med navn som begynner med ERROR_-suffikset.

   De mest typiske feilene har følgende koder:

   • ERROR_INVALID_HANDLE = 6& - ugyldig håndtak
   • ERROR_CALL_NOT_IMPLEMENTED = 120& - kaller en funksjon i Windows 9x som kun er tilgjengelig for Windows NT
   • ERROR_INVALID_PARAMETER = 87& - feil verdi parameter

   Imidlertid returnerer mange funksjoner verdien til en forespurt parameter (for eksempel returnerer OpenFile verdien til filhåndtaket). I slike tilfeller bestemmes feilen av en annen spesiell Return&-verdi, oftest 0 eller –1.

2. Win32 APIer bruker strengt faste måter å overføre de enkleste datatypene på. a) ByVal...Så lenge

   Minst 80 % av argumentgjennomføringen gjøres ved å bruke lange variabler. Legg merke til at argumentet Alltid er ledsaget av søkeordet ByVal, og dette innebærer blant annet at det utføres en enveis dataoverføring - fra VB-programmet til API-funksjonen.

   B) ByVal...Som streng

   Denne typen dataoverføring forekommer også ganske ofte, og med argumentet også Alltid ByVal gjelder. Når en API-funksjon kalles, blir adressen til strengen skrevet til stabelen, så i dette tilfellet er toveis datautveksling mulig. Det er flere farer å være oppmerksom på når du arbeider med strenger.

   Den første er at minnereservasjon for en streng gjøres i det anropende programmet, så hvis API-funksjonen vil fylle strenger, må du opprette en streng før du kaller den nødvendig størrelse. For eksempel returnerer funksjonen GetWindowsDirectory banen til Windows-katalogen, som per definisjon ikke må være mer enn 144 tegn lang. Følgelig bør å kalle denne funksjonen se omtrent slik ut:

   WinPath$ = Space$(144) ' reserver en streng på _ 144 tegn Resultat& = GetWindowsDirectory& (WinTath$, 144) _ ' fyll bufferen ' Resultat& - det faktiske antallet tegn i _ katalognavnet WinPath$ = Left$(WinPath , Resultat&)

   Det andre problemet er at når du kaller en API-funksjon, konverteres kildestrengen til en intern representasjon, og når du avslutter funksjonen, omvendt. Hvis i dagene av Win16 denne operasjonen bare besto av å legge til en null byte på slutten av linjen, ble dette med bruken av Win32 lagt til transformasjonen av dobbeltbyte Unicode-kodingen til ANSI og omvendt. (Dette ble diskutert i detalj i artikkelen "Funksjoner ved arbeid med strengvariabler i VB", ComputerPress 10'99 og 01'2000). For nå, la oss bare merke oss at ved å bruke ByVal ... Som strengkonstruksjon kan du utveksle strenger med kun tegndata.

   B) ... Som alle

   Dette betyr at en minnebufferadresse vil bli skjøvet inn i stabelen, hvis innhold vil bli tolket av API-funksjonen, for eksempel, avhengig av verdien av andre argumenter. Imidlertid kan As Any bare brukes i Declare-setningen - når en spesifikk funksjon kalles, må en spesifikk variabel defineres som et argument.

   D) ... Som UserDefinedType

   Denne utformingen brukes også ofte når det er nødvendig å utveksle data (vanligvis i begge retninger) ved hjelp av en eller annen struktur. Faktisk er denne konstruksjonen en slags konkret implementering av As Any-overføringsformen, det er bare at i dette tilfellet er funksjonen konfigurert til en fast struktur.

   Formen på datastrukturen bestemmes av den spesifikke API-funksjonen, og det er programmererens ansvar å beskrive og reservere den på riktig måte i det anropende programmet. Dette designet Alltid brukt uten ord ByVal, det vil si at i dette tilfellet utføres overføring ved referanse - adressen til variabelen skrives til stabelen.

Eksempel på å kalle en API-funksjon

La oss illustrere det ovenfor ved å bruke eksemplet med bruk av to nyttige funksjoner for å jobbe med filer - lopen og lread, som er beskrevet som følger:

Erklær funksjon lopen Lib “kernel32” _ Alias ​​​​“_lopen” (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) As Long Erklær funksjon lread Lib “kernel32” _ Alias ​​​​“_lread” (_ ByVal hFile As Long, lpBuffer som alle, _ ByVal wBytes så lenge) så lenge

I VB er deres analoger - i dette tilfellet eksakte - Open- og Get-operatorene (for binær modus). La oss umiddelbart ta hensyn til bruken av Alias-søkeordet i en funksjonserklæring - dette er akkurat tilfelle når du ikke kan klare deg uten det. Faktiske funksjonsnavn i biblioteket begynner med en understrek (typisk C-språkstil), som ikke er tillatt i VB.

Filåpningsoperasjonen kan se slik ut:

Const INVALID_HANDLE_VALUE = -1 ' feil _ deskriptorverdi lpFileName$ = “D:\calc.bas” ' filnavn wReadWrite& = 2 ' lese-skrivemodus hFile& = lopen(lpFileName$, wReadWrite&) _ ' definer filbeskrivelsen Hvis hFile& = INVALID_HANDLE_VALUE Deretter _ ' feil ved åpning av filen ' spesifiser feilkoden CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' denne konstruksjonen fungerer ikke Slutt Hvis

Her må du ta hensyn til to punkter:

• som verdien av funksjonen får vi verdien av filbeskrivelsen. Feilen tilsvarer en verdi på –1;
• Det er nettopp i dette tilfellet at det ikke fungerer å kalle GetLastError-funksjonen - for å få en raffinert feilverdi, vendte vi oss til Err-objektet (vi snakket om muligheten for en slik situasjon ovenfor).

Innholdet i filen kan da leses, men dette forutsetter at programmereren må ha en viss forståelse av strukturen (akkurat som tilfellet er når man arbeider med vilkårlige binære filer). I dette tilfellet kan oppkalling av lread-funksjonen se slik ut:

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' read ekte nummer, 4 byte ' wBytes - antall data faktisk lest, ' -1 - feil... Type MyStruct x As Single i As Integer End Type Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' les data struktur, 6 byte

Vennligst merk igjen: det andre argumentet til funksjonen sendes ved referanse, resten sendes av verdi.

Dim MyVar As String MyVar = Space$(10) ‘reserver en variabel for 10 tegn wBytes = lread (hFile&, ByVal MyVar, Len(MyVar)) ‘ les en tegnstreng, 10 tegn

Her kan du se en viktig forskjell fra forrige eksempel - strengvariabelen er nødvendigvis ledsaget av søkeordet ByVal.

Å lese innholdet i en fil i en matrise (for enkelhets skyld vil vi bruke en endimensjonal byte-matrise) gjøres som følger:

Dim MyArray(1 To 10) As Byte wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ‘ les 10 array-elementer

Ved å spesifisere det første elementet i matrisen som et argument, sender vi adressen til begynnelsen av minneområdet reservert for matrisen. Selvfølgelig kan du fylle et hvilket som helst fragment av en matrise på denne måten:

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ' les arrayelementer 4 til 8

Tips 5: Bruk Alias ​​​​for Gears og parametere som alle

Her, basert på det forrige eksempelet, vil vi avsløre essensen av Dan Applemans fjerde tips.

Når du arbeider med lread-funksjonen, bør du huske at når du får tilgang til den ved hjelp av en strengvariabel, må du bruke søkeordet ByVal (ellers vil du motta meldinger om en ulovlig operasjon). For å beskytte deg selv, kan du lage en ekstra spesiell beskrivelse av den samme funksjonen som kun fungerer med strengvariabler:

Erklær funksjon lreadString Lib “kernel32” _ Alias ​​​​“_lread” (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long) As Long

Når du arbeider med denne beskrivelsen trenger du ikke lenger å spesifisere ByVal når du kontakter:

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

Det ser ut til at syntaksen til Declare-operatoren lar deg lage en lignende spesiell beskrivelse for en matrise:

Erklær funksjon lreadString Lib “kernel32” Alias ​​​​“_lread” (_ ByVal hFile As Long, lpBuffer() As Byte, _ ByVal wBytes As Long) As Long

Imidlertid anken

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

fører uunngåelig til en fatal programfeil.

Dette er en fortsettelse av samtalen om særegenhetene ved å behandle strengvariabler i Visual Basic: VB bruker dobbelbyte Unicode-koding, Win API bruker enkeltbyte ANSI (og med formatet adoptert i C - med null byte på slutten) . Følgelig, når du bruker strengvariabler som et argument, utføres konverteringen fra Unicode til ANSI alltid automatisk når du kaller en API-funksjon (mer presist, en DLL-funksjon) og den omvendte konverteringen når du returnerer.

Uttaket fra dette er enkelt: Stringvariabler kan brukes til å utveksle tegndata, men de kan ikke brukes til å utveksle vilkårlig binær informasjon (som tilfellet var med 16-biters versjoner av VB). I sistnevnte tilfelle er det bedre å bruke en endimensjonal byte-array.

Som du vet, kan String-typen brukes til å beskrive en tilpasset struktur. I denne forbindelse må du huske følgende:

• Det er strengt forbudt å bruke følgende konstruksjon for å få tilgang til Win API: Type MyStruct x As Single s As String ' string variabel lengde Slutttype

  Når det gjelder en streng med variabel lengde, sendes en strengdeskriptor som en del av strukturen med alle påfølgende konsekvenser i form av en programkjøringsfeil.

• Du kan bruke en streng med fast lengde som et strukturelement: Type MyStruct x As Single s As String*8 ' fastlengde streng End Type

I dette tilfellet utføres den tilsvarende kodingskonverteringen.

Og en siste merknad: under ingen omstendigheter bør du bruke en rekke strengvariabler (både fast og variabel lengde) når du får tilgang til en API-funksjon. Ellers vil fremveksten av en "ulovlig operasjon" være garantert.

Det er sannsynlig at du vil ha en situasjon der du trenger å skrive dine egne DLL-funksjoner. Behovet for dette vil uunngåelig oppstå hvis du bruker blandet programmeringsteknologi - ved å bruke to eller flere programmeringsspråk for å implementere en applikasjon.

I denne forbindelse bemerker vi at blandet programmering er ganske vanlig for å implementere en ganske kompleks applikasjon. Faktisk har hvert språk (mer presist, et programmeringssystem basert på et språk) sine egne styrker og svake sider, så det er fornuftig å dra nytte av ulike verktøy for å løse ulike problemer. For eksempel VB - for å lage et brukergrensesnitt, C - for effektiv tilgang til systemressurser, Fortran - for implementering av numeriske algoritmer.

Forfatterens mening er denne: all seriøs programmering krever at utvikleren er dyktig i minst to verktøy. Selvfølgelig, under moderne forhold med en klar arbeidsdeling er det veldig vanskelig å være en utmerket ekspert selv i to systemer, så ordningen med "hoved- og hjelpespråk" er mer logisk. Tanken her er at selv en overfladisk kunnskap om "hjelpespråket" (å skrive ganske enkle prosedyrer) kan i stor grad forbedre effektiviteten ved bruk av "hovedspråket". Merk at kjennskap til VB, i hvert fall som hjelpemiddel, i dag nærmest er et obligatorisk krav for en profesjonell programmerer. Forresten, i DOS-dagene var kunnskap om det grunnleggende om Assembler ekstremt ønskelig for enhver programmerer, inkludert Basic.

På en eller annen måte, selv i gruppearbeid, når hver programmerer er engasjert i sin egen spesifikke oppgave, en idé om funksjonene til det prosedyremessige grensesnittet i forskjellige språk alle prosjektdeltakere skal ha. Og vet at mange programmeringssystemer (inkludert VB), i tillegg til standardgrensesnittet, lar deg bruke andre, avanserte metoder for å få tilgang til prosedyrer som gjør det mulig å tilpasse grensesnittet til et annet språk.

Når du studerer det interprosedyremessige grensesnittet, bør du være oppmerksom på følgende mulige fallgruver:

• Ulike språk kan bruke forskjellige konvensjoner for å skrive identifikatorer. For eksempel er det vanlig å bruke en understrek i begynnelsen av et prosedyrenavn, noe som ikke er tillatt i VB. Dette problemet løses enkelt ved å bruke Alias-søkeordet i Declare-setningen (se eksempeltips 2.3).
• Kan bli brukt annen rekkefølge skriving sendte argumenter på stabelen. For eksempel, i DOS-dagene (jeg innrømmer ærlig, jeg vet ikke hvordan det ser ut nå i Windows-miljøet), skrev C argumenter fra slutten av listen, andre språk (Fortran, Pascal, Basic) - fra begynnelsen.
• Som standard ulike prinsipper overføring av parametere - etter referanse eller etter verdi.
• Ulike prinsipper for lagring av strengvariabler. For eksempel, i C (så vel som i Fortran og Pascal) bestemmes lengden på en streng av nullbyten på slutten av den, men i Basic er lengden skrevet eksplisitt i strengbeskrivelsen. Du må selvfølgelig huske på muligheten for å bruke forskjellige kodinger tegn.
• Ved overføring flerdimensjonale arrays Det bør huskes at forskjellige alternativer er mulige for å konvertere flerdimensjonale strukturer til endimensjonale (startende fra den første indeksen eller fra den siste, i forhold til todimensjonale arrays - "etter rader" eller "etter kolonner").

Med alt dette i betraktning, kan følgende anbefalinger formuleres:

• Bruk de enkleste, velprøvde metodene for å sende argumenter til DLL-funksjoner. Standardene som er tatt i bruk for Win API er ganske egnet som modell.
• Pass aldri arrays av strengvariabler.
• Vær veldig forsiktig når du sender enkle strengvariabler og flerdimensjonale matriser.
• Pass på å spesielt sjekke funksjonaliteten til mekanismen for å sende argumenter til den kalte prosedyren og tilbake. Skriv en spesiell test for å teste dataoverføring. Kontroller separat at hvert argument sendes riktig. For eksempel, hvis du har en prosedyre med flere argumenter, må du først kontrollere at hver parameter sendes riktig for ett-argument-alternativet, og først deretter for hele listen.

Men hva om DLL-funksjonen allerede er skrevet, for eksempel i Fortran, men inngangsgrensesnittet passer ikke så godt inn i de ovennevnte VB-standardene? Det er to råd her. Først: skriv en test DLL-funksjon og bruk den til å prøve å finne ønsket anrop fra VB-programmet ved å prøve og feile. For det andre: skriv en adapterprosedyre i samme Fortran som vil gi et enkelt grensesnitt mellom VB og en DLL-funksjon med konvertering av enkle datastrukturer til komplekse (for eksempel konverter en flerdimensjonal byte-array til en string-array).

Så: bruk DLL-funksjoner. Men vær på vakt...

ComputerPress 9"2000

Russisk oppslagsbok om Win32 API