RR napisał(a)
deus przyznam, że nie wiem co za różnica czy winapi czy nie, jak i tak biblioteka inpout32 korzysta z winapi. Jest "nakładką" i muszę przyznać, że jeśli chodzi o LPT to dość przyjemną :), bo pięknie udostępnia dwie funkcje Inp32 i Out32, więc ja osobiście korzystam z tej biblioteki z przyjemnością.
PS. dostępny jest też kod źródłowy tej bibioteki, więc można poczytać i zobaczyć jak się robi poszczególne rzeczy.
Oczywiście jeszcze dodam, że najlepszym sposobem gadania z drukarką LPT jest po prostu otwarcie pliku "LPT" i pisanie do niego. Własna implementacja gadania z drukarką jest zupełnie zbędna, aczkolwiek przydatna, jeśli myślimy o własnym urządzeniu podpiętym pod drukarkę.
Poprawcie jeśli się mylę z tym plikiem.
No wiec nie jest do konca nakladka (ta biblioteke, ktora znam), ona z zasobow kopiuje sterownik (hwinterface.sys) i dopiero na nim dziala (zatem nie bezposrednio bez
niczego z samym WinAPI a dojscie do jadra - pytanie co rozumiemy przez winapi - teoretycznie obsluga/tworzenie sterownikow tez sie tu zalicza). Tu chodzi mi bardziej o przywileje. Bo np.
- Mamy dostep do LPT, nie mamy innych praw zwiazanych ze startem sterownikow - CreateFile wystarczy, inpout32 niezadziala
- Mamy dostep do instalacji sterownikow - inpout32 zadziala i LPT zadziala
Istotnie najlepiej bedzie z portem rozmawiac
otwierajac LPT za pomoca CreateFile (dostepne elementy dla drukarek), zostaje jescze DeviceIoControl (co prawda testowalem tylko dla RS'a).
duzo o
http://www.lvr.com/parport.htm
emulowac w taki sposob:
Port[$378]:=1
moze byc trudno, latwiej w klase ubrac i
Port.Port[$378]:=1
cos na ksztalt np. Canas.Pixels[x,y] = czerwony
i wtedy dodac do klasy funkcje z inpout32 (ale to bez sensu, tylko dla zapisu ...).
Duzo odwagi u wykladowcy :) ja bym co najwyzej poswiecil komplet ledow ... chyba ze drukarka warta tyle co dwubarwny LED.
A wlasciwie jak nie zakazuje to przynies dyskietke/cd/flasha/... z freedosem i programem w TP