SetCommMask()

Jag har laddat ner giveio och installerat det, men det fungerar inte.

Jag testade själv på XP Pro (svensk) och det fungerar utmärkt. Hur installerade du den? Om man bara står i system32\drivers på XP och skriver: "instdrv giveio giveio.sys" så kommer det inte att funka. Du måste se till att registernyckeln:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\giveio\imagepath

har värdet: "system32\drivers\giveio.sys".
Sen går det att starta med: "net start giveio" och "CreateFile" kommer också att returnera en "valid handle".

Om det sen gör att din kod med SetCommMask kommer att fungera är, som sagt, mer osäkert. Men jag tycker det är värt ett försök.

Nej, det fungerar inte. När jag kör net star får jag meddelandet :
"systemfel 3 har uppstått.
Det går inte att hitta sökvägen."

????

OK? Prova att skriva "\??\<hela sökvägen>" i registernyckeln.

Alltså tex: "\??\c:\windows\system32\drivers\giveio.sys".

Det ska också funka. Du har väl förresten placerat filen i mappen "drivers"?

Ha ha det fungerar, tack.
Nu ska jag prova med SetCommMask och sånt, jag hör av mig snart!!!

Nej, det fungerar inte med SetCommMask

OK. Trist. :l Men du har ju ett par options kvar. Dels developers variant, dels min länk där uppe: http://www.entechtaiwan.com/tviclpt.htm. Men borde du inte sova en stund först? :)

Det bästa hade varit om jag hade kunnat använda en dll fil, som io.dll fast med interrupts.
Vet någon var man får tag i sånt??

Jag känner nu att jag kanske ska tala om varför jag vill ”läsa av” LPT porten…
Jo, jag har byggt en liten elektronisk krets som ska avkoda DTMF tonerna till bitar.
Det är alltså en nummerpresentatör till PC.

Reza skrev:

Det bästa hade varit om jag hade kunnat använda en dll fil, som io.dll fast med interrupts.

Fast io.dll är inte en stand-alone dll. Den innehåller en driver (io.sys) som den dumpar till disk och installerar och startar. io.sys fungerar sen "i princip" som giveio.sys.

Reza skrev:

Vet någon var man får tag i sånt??

På sidan jag länkade till så står det att det kitet hanterar interrupts från parallellporten. Finns säkert sample-kod. Har du provat?

Annars har jag nog inte fler tips .. Tyvärr. :l

Det är jag igen, nu måste ni vara väldigt trötta på dessa frågor, förlåt…
Varje gång DTMF tonerna är på ingång får min app en Busy signal på LPT pin 11.
Är det ok att loppa och checka denna värde, är det signal på pin 11 utför jag något annars fortsätter loppen?

Jag vill helst inte betala 1000:- för en sån kit som hanterar interrupts från parallellporten.

Är ingen expert på sånt här men det är ju sjävklart mer optimalt att använda interrupts än att polla. Men sen beror det ju helt och hållet på hur ofta man är tvungen att polla för att inte missa data. Du märker ju själv hur systemet påverkas när du testar? Om processorn ligger på 100 % och musen knappt går att flytta så .. annars är det väl OK?

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.dll:er som förmodligen ställer till med mer problem senare.

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 ..

Reza skrev:

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…

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/microsoft.public.win32.programmer.kernel

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 ..

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 :p

PeW skrev:

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

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:

void main()
{
	__asm cli
}

PeW skrev:

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.

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 API:erna: 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.

Jag tänker inte käbbla emot dig på hur man normalt använder winAPI och systemanropen... men:

En driver behöver inte mycket till installationsfas

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.

Jag har väldigt svårt att tro att de via assembler "trixar" sig upp i kernel-mode utan att använda en driver.

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 winapi:ets 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 :e

developer skrev:

Det enda sättet att göra något i kernelmode är genom att skriva en drivrutin, det finns inga andra sätt.

Citerar mig själv raden under:

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

:e

PeW skrev:

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.

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

PeW skrev:

Jag har tidigare snappat upp ditt problem i andra forum

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. :q

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.

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.