SetCommMask()

[PeW]

Ska du gå förbi kernel är det lika bra att göra det ordentligt med asm (kapitel 21) istället för att krångla till det med generic-drivers och lullull.dllr som förmodligen ställer till med mer problem senare.

[niko]

Man kan inte "gå förbi kerneln" i XP genom att skriva i assembler. Koden måste fortfarande ligga i en driver. Och vill man sen inte skriva denna själv så får man använda en "generic". Dom bitarna går liksom inte att komma runt ..

[developer]

[citat=Reza]developer, jag har suttit med det här problemet i flera dag nu (sovit bara några timmar).
Vill du vara så snäll och skriva ett exempel på hur jag väntar på inkommande data och hur jag läser det med hjälp av USBLPTPD11.SYS.
Får jag det här att funka nu kan jag sova ikväll… [/citat]Sådant är livet

Har inte använt parallellporten själv på det sättet, så jag har tyvärr inget exempel att hosta upp. Jag hade ställt frågan här: news://msnews.microsoft.com/microsof...grammer.kernel

[PeW]

[citat]Man kan inte "gå förbi kerneln" i XP genom att skriva i assembler. Koden måste fortfarande ligga i en driver. Och vill man sen inte skriva denna själv så får man använda en "generic". Dom bitarna går liksom inte att komma runt ..[/citat]Jag menade inte att du ska gå förbi kernel, jag tolkade din frågeställning som att du försöker det. Det man ist kan göra är att på nåt sätt komma åt kernelmode och då utan att installera generella drivers eller använda win32-anrop.
Det går att göra detta med NT-kernels... Diskuteras bl.a här -> http://www.windowsitlibrary.com/Content/356/09/1.html ... det finns ju en del program som kör t.ex nullmodem uppkopplingar genom lpt och på NT - utan att det utförs nån installationsfas på systemet i sig.

*Att det sen mer eller mindre innebär att man skriver en egen driver gör det kanske OT

[developer]

[citat=PeW]Det man ist kan göra är att på nåt sätt komma åt kernelmode och då utan att installera generella drivers eller använda win32-anrop.
Det går att göra detta med NT-kernels... Diskuteras bl.a här -> http://www.windowsitlibrary.com/Content/356/09/1.html[/citat]Eh, hur menar du nu? Artikelns hookint.sys är ju just en drivrutin. Det enda sättet att göra något i kernelmode är genom att skriva en drivrutin, det finns inga andra sätt. Prova exempelvis koden i artikeln från usermode:[kod]void main()
{
__asm cli
}[/kod]

[niko]

[citat="PeW"]
det finns ju en del program som kör t.ex nullmodem uppkopplingar genom lpt och på NT - utan att det utförs nån installationsfas på systemet i sig.
[/citat]

En driver behöver inte mycket till installationsfas. Det enda som krävs är några registernycklar för att Windows ska veta när och hur drivern ska startas.

Vad många applikationer däremot gör, precis som jag skrev ovan om io.dll, är att de utför detta i bakgrunden, dolt för användaren. Dvs de reggar och startar drivern "on the fly" via de sedvanliga APIrna: CreateService, OpenService, StartService .. (Applikationen måste ha administratörsrättigheter när detta utförs.)

Om de program du talar om accessar parallellporten med direkt IO och interrupts så är det förmodligen så de gör. Jag har väldigt svårt att tro att de via assembler "trixar" sig upp i kernel-mode utan att använda en driver.

[PeW]

Jag tänker inte käbbla emot dig på hur man normalt använder winAPI och systemanropen... men:
[citat]En driver behöver inte mycket till installationsfas[/citat]Jag skrev för tusan inte hur mycket installation det krävs eller vad för installation - vad du tar för givet om vad jag avser får stå för dig.
[citat]Jag har väldigt svårt att tro att de via assembler "trixar" sig upp i kernel-mode utan att använda en driver.[/citat]Du missförstår totalt vad jag menade. Det är inte nåt mer "revolutionerande" med assembler än andra språk om man endast arbetar mot winapits systemanrop.. däremot är de drivers som vandrar in i HAL asm-specifika på lågnivå och där duger det inte med nåt annat. Jag har tidigare snappat upp samma problem i andra forum och tänkte passa på att "tipsa" om detta - men hur det sen blir med det får man väl söka själv eller lägga ned. Hur det sen blir med den saken skiter jag högaktningsfullt i

[PeW]

[citat=developer]Det enda sättet att göra något i kernelmode är genom att skriva en drivrutin, det finns inga andra sätt.[/citat]
Citerar mig själv raden under:[citat]*Att det sen mer eller mindre innebär att man skriver en egen driver gör det kanske OT[/citat]

[niko]

[citat="PeW"]
däremot är de drivers som vandrar in i HAL asm-specifika på lågnivå och där duger det inte med nåt annat.
[/citat]

Jo, det gör det visst! Drivers skrivs normalt i C med anrop mot Kernel-APIt. 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.)

Vad betyder förresten "vandra in i HAL" och "asm-specifik"? Är det hemmagjorda termer?

[citat="PeW"]
Jag har tidigare snappat upp ditt problem i andra forum
[/citat]

Vad? Mitt problem? Jag har inte ställt nån fråga. Däremot har jag försökt svara på Rezas fråga, om det är det du menar?

Och slutligen: Eftersom vi redan är off-topic och jag inte kan förstå logiken i nåt av dina fyra senaste inlägg så lägger jag ner diskussionen.

[Beatbox]

[citat]En driver behöver inte mycket till installationsfas. Det enda som krävs är några registernycklar för att Windows ska veta när och hur drivern ska startas.
[/citat]

Från 200 och frammåt så rekommenderar Microsoft att man använder sig at Devicemanager då man installerar eller uppdaterar drivrutiner och då blir det väldigt lätt i alla fall.

[Reza]

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.

[niko]

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.

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 WindowsAPIrna 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/de.../sspd_3kiv.asp

och här: http://msdn.microsoft.com/library/de.../sspd_8wfb.asp

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

[citat="Reza"]
Jag vill rekommendera io.dll för ”vanliga” läs och skriv operationer på LPT, den fungerar och är dessutom helt gratis.
[/citat]
Ett annat gratisbibliotek förutom io.dll som också fungerar bra är WinIO: http://www.internals.com/ (klarar tyvärr inte heller interrupts).

[PeW]

[citat]Jo, det gör det visst! Drivers skrivs normalt i C med anrop mot Kernel-APIt.[/citat]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å. [citat] 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.)[/citat]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

[niko]

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.

[citat="PeW"]
Nja... vissa saker kan inte utföras i enbart C.
[/citat]
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-APIt? 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.
[citat="PeW"]
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.
[/citat]
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 ..
[citat="PeW"]
Det jag är ute efter är att skriva direkt till porten från appsen.
[/citat]
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.
[citat="PeW"]
så varför inte endast läsa port och hämta tecken direkt?
[/citat]
Från usermode? Isåf se ovan!
[citat="PeW"]
Vill man absolut använda systemcalls och förmå windows till detta så är inte mitt förslag gångbart.
[/citat]
Å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.
[citat="PeW"]
Kändes bara som overkill för en sån här uppgift eftersom det tydligen ger problem
[/citat]
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).

[developer]

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.