SetCommMask()

Hej igen
Jag håller på att prova toolkiten som niko rekommenderade.
Det är nog det enklaste sättet att få det hela att fungera i NT/2000/XP.

Jag vill tacka för alla tips som jag har fått, återkommer med mer information så fort det fungerar.
Jag vill rekommendera io.dll för ”vanliga” läs och skriv operationer på LPT, den fungerar och är dessutom helt gratis.

Jag har kollat lite vidare själv. Tyvärr verkar det vara så att det finns många gratis driver-kits som klarar läsningar/skrivningar medan alla som klarar interrupthantering kostar pengar. :l

En annan väg som jag funderade på eventuellt kunde vara framkomlig skulle vara att utnyttja de befintliga parallelldrivers som redan finns i systemet (parport.sys bla). Via WindowsAPI:erna DeviceIoControl och DefineDosDevice borde det kanske gå att komma åt funktioner som har med interrupts och/eller callbacks att göra.

Det står lite här: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/parallel/hh/parallel/sspd_3kiv.asp

och här: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/parallel/hh/parallel/sspd_8wfb.asp

om du nu har tid och lust att grotta i det ..?

Reza skrev:

Jag vill rekommendera io.dll för ”vanliga” läs och skriv operationer på LPT, den fungerar och är dessutom helt gratis.

Ett annat gratisbibliotek förutom io.dll som också fungerar bra är WinIO: http://www.internals.com/ (klarar tyvärr inte heller interrupts).

Jo, det gör det visst! Drivers skrivs normalt i C med anrop mot Kernel-API:et.

Nja... vissa saker kan inte utföras i enbart C. Men det är säkert rätt att t.ex winDDK kör med C-kod som lägsta nivå.

Assembler är något man bör undvika så långt som möjligt i driver-utveckling eftersom det ger processorspecifik icke-portabel kod. (Du kan nog kolla med developer om du inte tror mig.)

Men snälla du. Jag tror dig... det som jag dock inte håller med om är att man nödvändigtvis måste använda systemanrop för en sån här sak. Att assembler ger processorspecifik kod är mindre intressant i det här fallet då de flesta klientmaskiner som ö.h.t kör windows idag har intel-standard. Möjligt att portadresserna kan skilja sig åt på olika kort, dock - det låter jag vara osagt. Det jag är ute efter är att skriva direkt till porten från appsen. Då det inte handlar om att buffra, bearbeta bitar eller nåt annat som kräver minnesmappning så varför inte endast läsa port och hämta tecken direkt?

Vill man absolut använda systemcalls och förmå windows till detta så är inte mitt förslag gångbart. Kändes bara som overkill för en sån här uppgift eftersom det tydligen ger problem, därav min inblandning i diskussionen. Endera gör man si eller så... svårare än så behöver det inte vara :birp

Skrev visserligen att jag lagt ner diskussionen, men eftersom Reza verkar ha avslutat tråden från sitt håll och du framhärdar, så är jag väl inte sämre än att jag kan ta upp den igen. :)

PeW skrev:

Nja... vissa saker kan inte utföras i enbart C.

Jaha? Exempel vore trevligt? De relevanta sakerna i det här fallet är att läsa, skriva, och ta över interrupts. Vilka av dessa görs inte enklast i C mot Kernel-API:et? WRITE_PORT_UCHAR, READ_PORT_UCHAR, HalGetInterruptVector låter som lämpliga anrop i mina öron ..

Huvudsyftet med HAL, som du talar om, är ju just att erbjuda ett arkitektursoberoende interface/API mot hårdvaran så att man slipper använda assembler.

PeW skrev:

det som jag dock inte håller med om är att man nödvändigtvis måste använda systemanrop för en sån här sak.

Systemanrop? Var? Reza anropar usermodefunktioner i en dll (io.dll) som i sin tur mappar mot kernelmodefunktioner i en driver (io.sys). Vilka av dessa ska ersättas med icke-systemanrop i assembler? I usermode går det inte. Och i kernelmode finns det ingen anledning. På den här punkten är du väldigt svävande ..

PeW skrev:

Det jag är ute efter är att skriva direkt till porten från appsen.

Ja. Och det är ju exakt det som inte går. Man kan inte skriva direkt till porten från en app i NT/2000/XP oavsett om den är skriven i maskinkod, assembler, C, JavaScript, HTML eller något annat. (I alla fall inte om man inte använder odokumenterade features/buggar i operativet som kan sluta att fungera med nästa service pack.) Antingen gör man det via en befintlig driver (den lösning du hävdar är krånglig och ger problem) eller så skriver man en egen driver (som du tycks föreslå). Det finns inget tredje sätt.

PeW skrev:

så varför inte endast läsa port och hämta tecken direkt?

Från usermode? Isåf se ovan!

PeW skrev:

Vill man absolut använda systemcalls och förmå windows till detta så är inte mitt förslag gångbart.

Återigen: Begränsningen består inte i att man använder "systemcalls". Begränsningen ligger helt och hållet i det faktum att man befinner sig i usermode. Så länge man befinner sig i usermode (på fel sida om IRQ-gate:n) kan man inte göra vissa saker oavsett om man skriver i assembler, eller inte. För att göra det Reza vill så måste man befinna sig i kernelmode dvs kod som ligger inne i en driver.

PeW skrev:

Kändes bara som overkill för en sån här uppgift eftersom det tydligen ger problem

Problem? Läsningar och skrivningar fungerar. Problemet är att det är svårt att hitta en gratis lösning som tillhandahåller interrupthantering. Alternativet att skriva en egen driver, vilket i praktiken blir vad du föreslår, är nog väldigt mycket krångligare. Vi talar veckor/månader med blåskärmar och buggar (helt beroende på hur erfaren man är och vilken typ av driver man skriver). Sen får ju även den nya drivern en installationsfas som du talar om tidigare. Den måste insertas på rätt ställe i driverstacken (om man inte helt avser att ersätta den befintliga).

Niko, jag instämmer till fullo.

Kan förtydliga att poängen med att en processor stöder olika rings, som operativsystemet utnyttjar är just den här typen av skydd. Vanliga program ska inte komma åt hårdvara, det skulle orsaka instabilitet.

Intel-processorer stöder 4 rings, vara Windows använder 2, nämligen Ring 0 (som kallas kernelmode i Windows) och Ring 3 (usermode). Vanliga program och services körs i usermode, NTs "kärna" (som är några olika komponenter) och drivrutiner exekverar i kernelmode.

Om man kunde komma åt hårdvaran direkt skulle dels operativsystemet inte vara stabilt, exempelvis eftersom vilket program som helst skulle kunna skriva till controller-kortet för hårddisken. Dessutom skulle operativsystemet inte vara säkert. Windows (och andra operativsystems) hela säkerhetsstruktur bygger på att säkerheten finns i kernelmode så usermode program inte kan påverka den.

Har en bra bok om detta

Oj vilket käbbel :)
Jag jobbar en del med detta dagligen, men orkar inte ge mig in i den vilda diskussionen...

Kan rekommendera Windows NT device driver development, viscarola (har den själv)

Och Karen hazzah's bok om VxD

Det är inte enkelt att fixa detta själv, det är mycket att tänka på ,databuffring, synkronisering mm. mm. Och tyvärr är det inte så lätt att man bara skriver eller läser direkt till porten från applikationen, datan måste flöda genom hela op-systemets struktur...

Där är serieporten enklare, den betraktas mer eller mindre son en fil.

Däremot finns flera 3:e partsprogram som funkar lysande, och som är ganska så modifierbara, men de kostar en slant...

Ännu en gång tack för all hjälp och tips.

Jag kör nu med TVicHW32 5.0 och det fungerar bra, jag kommer att köpa den efter årsskiftet.
Jag var dock tvungen att ändra lite i min bygge för att kunna använda TVicHW32s interrupt hantering.

God jul och Gott nytt år på er alla.

niko ->
Tack för föreläsningen... men den tillförde inget jag inte redan kände till och du verkar inte riktigt fatta poängen med det jag yppade ;)

Enda enda anledningen till att jag la mig i är att det trots allt är fullt möjligt att smacka ihop en comfil som läser av bitarna från en port på IO-bussen och köra det programmet under NT. Det har inget med winAPI-calls att göra alls - varav min (som du verkar fatta den) "motsträvighet" :birp

Ah! Tråden som vägrar dö. Kul. :)

PeW skrev:

Tack för föreläsningen... men den tillförde inget jag inte redan kände till

Synd. :( Men då drev du alltså med mig när du skrev att du trodde att det bara dög med assembler för att kommunicera med HAL? ;)

PeW skrev:

du verkar inte riktigt fatta poängen med det jag yppade

Nej, och det har jag också själv påpekat ett flertal gånger. Inget av dina inlägg har innehållit minsta lilla vink om hur du egentligen avser att man ska gå till väga. När dessutom din enda kodlänk pekar på en kernelmodedriver i C med några rader assembler så minskar du ju inte direkt förvirringen.

PeW skrev:

att det trots allt är fullt möjligt att smacka ihop en comfil som läser av bitarna från en port på IO-bussen och köra det programmet under NT

Tack! Äntligen fattar jag. Vad du alltså hela tiden syftat på är alltså att skriva en gammal 16-bitarsapplikation?

OK. Visst. Av bakåtkompatibilitetsskäl så ser operativet till att 16-bitarsapplikationer tror att de har direkt I/O-access.När en 16-bitarsapplikation försöker komma åt en I/O-port så fångar operativet detta och skickar det vidare till en VDD i sin tur som anropar den korrekta funktionen i en kernelmode-driver.

Om man så vill så kan man kalla detta "ett tredje sätt" att få I/O-access som jag inte tog med däruppe. Det har du rätt i.

Fast fler frågor uppstår:

Är det en option i dagens läge att skriva stand-alone 16-bitarsapplikationer för XP bara för att få I/O-access utan "lullull.dll:er" och drivers? Tveksamt ..

Som jag skrivit ovan så är ju läsningar och skrivningar inget problem, i vilket fall som helst (Reza hade fixat det innan tråden startade). Det stora kruxet är ju interrupthanteringen. Har du något exempel på att detta går att komma åt på XP från en 16-bitarsapp? Eftersom inga av gratis-kiten innehåller detta så kan man ju misstänka att det nog inte är helt lätt. Men som sagt, jag vet inte och det skulle vara intressant med ett exempel ..

Men då drev du alltså med mig när du skrev att du trodde att det bara dög med assembler för att kommunicera med HAL?

Nej, det är din tolkning av vad jag "tror". Att det redan finns färdigdefinierade funktioner för kommunikation med HAL har inget med det jag skrev om att göra ;)

Inget av dina inlägg har innehållit minsta lilla vink om hur du egentligen avser att man ska gå till väga. När dessutom din enda kodlänk pekar på en kernelmodedriver i C med några rader assembler så minskar du ju inte direkt förvirringen.

Jag avsåg aldrig att komma med en "tutorial" för det har jag ingen. Jag har inte heller tid att sitta och vrida och vända på saken då studierna kräver mer än dygnets 24 timmar. Min inblandning var spontan och det är upp till den som vill tillämpa det att söka vidare om "när var hur" - om det skulle vara av intresse (därav mina länkar).

Vad du alltså hela tiden syftat på är alltså att skriva en gammal 16-bitarsapplikation?

Nej inte explicit, men jag åsyftar att eftersom det fungerar under en real-mode app som är 16 bitar så finns det hopp :e

Fast fler frågor uppstår:
Är det en option i dagens läge att skriva stand-alone 16-bitarsapplikationer för XP bara för att få I/O-access utan "lullull.dll:er" och drivers? Tveksamt ..

Beror på vad det är för applikation. Behöver man inte en massa buffring och synkronisering var iaf min tanke att det skulle vara ett "option". Det behöver inte vara en "stand-alone" även om det kanske inte är ett rumsrent sätt att göra det på. Det kan säkert vara smidigt med dll:er för denna uppgift. Uttryckte mig klumpigt och menade inte att "racka ned" på alla dll:er som är signerade av MS... sorry!

Av bakåtkompatibilitetsskäl så ser operativet till att 16-bitarsapplikationer tror att de har direkt I/O-access.När en 16-bitarsapplikation försöker komma åt en I/O-port så fångar operativet detta och skickar det vidare till en VDD i sin tur som anropar den korrekta funktionen i en kernelmode-driver.

Jepp. Det du skriver om är ntvdm... men vad är det emulatorn går efter? Instruktioner eller adresser?
*IN & OUT med port adress fungerar iaf på IO-bussen*

PeW skrev:

men vad är det emulatorn går efter? Instruktioner eller adresser?

Bra fråga! Vet ej exakt. Som jag har förstått det så har processer som kör inuti NTVDM:en en begränsad tillgång till vissa I/O-portar. Däremot så har de naturligtvis inte fullt "kernelmode-blås" på instruktionsnivå i den bemärkelsen att de kan komma åt tex disk-controllern eller flasha om BIOS:en. Om det varit så, så hade det nog vimlat av 16-bitars virus för alla NT-plattformar, vilket det som tur är inte gör .. :)

Misstänker också att MS inte har något större intresse av att vara glasklara på den här punkten eftersom de antagligen inte vill att folk ska fortsätta skriva 16-bitarsapplikationer och därmed behöva behålla stödet i all evighet.

niko skrev:

...16-bitarsapplikationer och därmed behöva behålla stödet i all evighet.

I 64-bitars Windows är det 16-bits stödet helt borttaget om jag inte minns fel.