SetCommMask()

[Toonster]

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 partsprogram som funkar lysande, och som är ganska så modifierbara, men de kostar en slant...

[Reza]

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

[PeW]

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"

[niko]

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

[citat="PeW"]
Tack för föreläsningen... men den tillförde inget jag inte redan kände till
[/citat]
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?

[citat="PeW"]
du verkar inte riktigt fatta poängen med det jag yppade
[/citat]
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.

[citat="PeW"]
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
[/citat]
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.dllr" 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 ..

[PeW]

[citat]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?[/citat]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
[citat]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.[/citat]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).

[citat]Vad du alltså hela tiden syftat på är alltså att skriva en gammal 16-bitarsapplikation?[/citat]Nej inte explicit, men jag åsyftar att eftersom det fungerar under en real-mode app som är 16 bitar så finns det hopp

[citat]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.dllr" och drivers? Tveksamt ..
[/citat]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 dllr för denna uppgift. Uttryckte mig klumpigt och menade inte att "racka ned" på alla dllr som är signerade av MS... sorry!

[citat]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.
[/citat]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*

[niko]

[citat="PeW"]
men vad är det emulatorn går efter? Instruktioner eller adresser?
[/citat]

Bra fråga! Vet ej exakt. Som jag har förstått det så har processer som kör inuti NTVDMn 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 BIOSn. 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.

[developer]

[citat=niko]...16-bitarsapplikationer och därmed behöva behålla stödet i all evighet.[/citat]I 64-bitars Windows är det 16-bits stödet helt borttaget om jag inte minns fel.