Szia Zsolt!

>>>Nem tudja veletlenul valaki, hogy milyen feltetelek teljesulese mellett
>>>olvashat egy NT alatt futo program tetszoleges I/O portokrol? (Vezerlesi
>>>feladatot kellene megoldani a PrinterPort vagy spec. I/O kartya (8255)
>>>felhasznalasaval.)
 ...
>Termeszetesen van Win SDK helpem (bongesztem is szorgalmasan):
>Van prot olvasasi tamogatas a Win32-ben (_inp, _outp (byteos, wordos es
>dwordos)), de azzal a megjegyzessel, hogy csak Win95 alatt megy. Egyeb,
>portokra vonatkozo utalast nem talaltam a help-ben.

Valoban, hiszen gondold vegig mi lenne a programmal pl. Alpha vagy RISC
platformokon?

>Elkepzeleseim szerint valami nagyon buta VxD-t kellene irni, ami
>inicializalaskor magahoz veszi a megadott I/O port kezeleset, es
>hozzafereset biztosit a progra(mok/mom) szamara. A baj azzal van, hogy meg
>tavolrol sem lattam Driver Development Kit-et (csak olvastam rola). Nincs
>valakinek hozzaferese ilyesmihez?

Igen csak nem vxd hanem sys. A win98 es NT 5.0 ddk ingyen letoltheto MS-tol
(gondolom  nem a vegleges verzio) az NT 4.0 DDK-jat sulyos penzekert merik.
A ddk-ban van peldaprogram a COM/LPT portok kezelesere. Egyebkent NT alatt
meg kernel szintu driverekbol sem lehet buntetlenul in / out utasitasokat
kiadni!

Egyet nem ertek, miert nem jo neked a standard CreateFile megoldas???

Ha irsz egy miniport drivert, akkor azzal is csak a standard file I/O-n
keresztul fogsz tudni kommunikalni, hiszen egy user szintu program nem
hivhat kozvetlenul kernel szintu rutinokat es forditva sem. Igy a
kifele meno adatokat meg akar egy custom ioctl-n keresztul is atadhatod,
de ami a portrol erkezik azt csak vagy egy asyncron (overlapped) read-del
olvashatod netan 1 semaphorra varakozol egy threadben es figyeled van-e
adat (WaitForSingleObj...) Esetleg mailslot-ot hasznalsz a kommunikaciora.
Persze vannak meg mindenfele csunya megoldasok, mint a user addr space-ba
mappolt kernel memoriateruletek, de ezek a megoldasok vezetnek egyenesen
a kek halalba...

Ja igen es a miniport driverek irasa sem leanyalom nem art ha van a
DDK+SDK! mellett meg egy gep a remote debugghoz es nagy adag turelem
a sok reboot miatt. Egyszoval nem hiszem, hogy a megoldas sokkal gyorsabb
lenne.

Egyebkent az letezik egy ugy emlexem egy eleg hirhedt Intel platformokra
irt "buta device driver" ami az intel procik egy "hibajat" kihasznalva
lehetove teszi Ring3-rol (itt fut az NT user level) a kozvetlen I/O-t,
ezt egy Dale Roberts nevu uriember irta.
Ez kenyelmes akkor ha az Mber pl device drivert ir de jol haza lehet vagni
vele  a rendszert, kinyirni egy NTFS particiot stb stb...

No bocs hogy velem van tele mostanaban a GURU de most volt egy kis idom
irogatni.

udv: Gabo

> ================================================
Bala'zs Ga'bossy
 / 

Sziasztok!

Mar regota szerettem volna irni a subject beli temaval kopcsolatban,
de sajna nagyon keves az idom mostansag. Kozben jottek a temaban
hozzaszolasok nos ezekhez szeretnek meg nehany dolgot hozzafuzni.

Eloszor egy dolgot kellene leszogezni. Sajnos ugy veszem eszre
sokan laikusok, szakemberek egyarant egy kalap ala veszik a
WinNT-t a Win95-tel. Ez nem egeszen korrekt allaspont, ha
rendszerszinten vizsgaljuk oket, meg csak nem is hasonlitanak
egymasra. A kerdesek igy nagyon sokszor felreerthetoek. Levelemmel
szeretnek nehany felreertest tevhitet eloszlatni, remelem nem
irok tul sok butasagot, mert jelenleg nincs lehetosegem minden
allitasom leellenorizni igy memoriamra kell tamaszkodnom.

A napokban valamelyik GURU-ban valaki vxd-ket emlegetett NT
kapcsan, holott az NT device driverek vagy sys vagy dll
formatumu filek. Letezik, pontosabban futtathato vxd NT-n
is pl az MS java VM-jevel kapcsolatban hasznal egyet, de
ez nem mint device driver hanem csak mint user level dll
funkcional.

Visszaterve a subject beli temahoz:
A win95 a 16 bites alkalmazasokat egy kozos (kb 2G virtualis
cimtol) cimtartomanyba mappolja vonatkozik ez a hasznalt dos
device driverekre es a 16bites win3.11 programokra, igy fordulhat
elo, hogy egy 16 bites program elszallasa eseten a "viztorony
elonti a varost".

Az NT-nel mas a helyzet, ez a megoldas nem hasznalhato a
multiplatformos jelleg es biztonsagi megfontolasok miatt.
NT alatt letezik egy ugynevezett VDM Virtual DOS Machine
(ntvdm.exe) a vedett es real modu DOS (vonatkozik  ez a
TSR programokra is) es 16 bites win3.1 alkalmazasok ennek
a programnak a felugyelete alatt futnak.

Ebbol minden egyes DOS applikacio (real es prot modu egyarant)
inditasakor letrejon egy peldany amely peldanyok egymastol
teljesen fuggetlenek nem is lathatjak egymast (ezert is sokkal
tobb memoriat igenyel a futtatasuk).
A 16bites win3.1 alkalmazasokat pedig egy kozos vdm futtatja
illetve ezen belul egy ugynevezett Windows on Win32 azaz
(wowexec.exe ha ismeros). Amely megteremti a win3.1 futasi
kornyezetet a programnak. A vdm egy dos program idulasakor
a \system32\autoexe.nt es \system32\config.nt allomanyokat
hajtja vegre. Ezekbe lehet elhelyezni barmely    szukseges
eszkozmeghajot, programot mint dos-nal is na az mas kerdes
mukodik-e... A VDM feladata nem intel platformokon
az x86 -> nativ instr. kod atalakitas is.

No ez eddig szep es jo, tobbe kevesbe majdnem minden DOS
alkalmazas elfutkozgat mert ugy erzi magat mintha DOS-ban
lenne. A problemak akkor kezdodnek amikor jo dos szokasokhoz
hiven maga kezdi el matatni az I/O portokat pl egy specialis
kartyara lenne szuksege vagy eppen DMA transfert akar kerni
a kartya fele, nos ilyenkor szoktak a problemak kezdodni.
Klasszikus problema pl a videokartya izgatasa protszinten.
Itt lepnek be a kepbe a vdd-k azaz virtual device driverek.

A VDD-k tulajdonkeppen 32bites dll-ek amelyek user-modban
futnak, es arra hasznalhatoak, hogy mintegy elkapjak a 16bites
vagy protected modu dos alkalmazasok memoria, I/O vagy interrupt
hivatkozasait, es azokat illo modon lekezleve pl egy ioctl-lel
a megfelelo NT device drivernek tovabbitsak. Egeszen pontosan
a pl DOS program altal kivaltott exceptionokat vagy I/O
hivatkozasokat a VDM lekezeli es tovabbpasszolja a VDD-knek,
ha kell.

Nos azert vannak megkotesek pl eppen a VIDEO! vagy DMA
kezeleshez hasznalt I/O portok kozvetlen nem hookolhatoak
a vdd-bol, meivel maga az ntvdm kezeli oket (hat ugy ahogy)
gondolom ertheto miert.
Azert lehetseges athidalo megoldas ezekben az esetekben is.
Egyszoval egyaltalan NEM egyszeru vdd-t irni nem art ha az
Mber behato ismeretekkel rendelkezik NT ugyileg, es
supportalando DOS alkalmazas ismerete sem hatrany.


Aki annakidejen a kerdes felvetette egy bgi driverrel
meglevo  problemaja kapcsan nem irta le pontosan a lefagyas
tuneteit:

>Tudomasom szerint az NT tud futtatni DOS programokat, ez azonban
>egyszeruen lefagy, az NT DOS modjaban is. Mi lehet ennek az oka?

Mit irt ki? General Protection? vagy csak "ugy" marad?
Ezenkivul melyik bgi hivas azaz grafikus utasitas utan szall el?
A listan tobben  memoria cimzesi hibara tippeltek en
maganlevelben inkabb  I/O problemakra. Azert mivel a vdm altalaban
tudja hol kezdodik a videomemoria es lekezelei az  ilyen
jellegu hivatkozasokat, pl ha a dos a000:0000-ra akarunk irni
akkor atlalaban!!!  tudja, hogy videomemoria...

Sajna en nem ismerem mar tul jol a dos-os fejlesztoeszkozoket
foleg az ujabbakat (pl vesa) de mintha lattam volna valahol,
hogy letezik valamilyen vesa.bgi(???) amivel altalaban nincsenek
gondok NT alatt. (Hangsulyozom ezt csak lattam, olvasgattam
valamikor lehet szamarsag az informacio!).

Hat ennyi voltam jo hosszu :) Remelem nem tartottam fel senkit
es tul nagy butasagokat sem irtam.

udvozlettel:
Gabo

> ================================================
Bala'zs Ga'bossy
 / 

On 24 Oct 98 at 12:37, Kaproncai Tamas > wrote:

> >   test var,1 shl 13 + 1 shl 4
> >   jpe  ugyanaz ; ha paros paritasu, a ket bit azonos, nem kell csere
> >   xor  var,1 shl 13 + 1 shl 4     ; egyik bit 1, masik 0, xor cserel
> > ugyanaz:
> 
> ezt ki is probaltad? ez nem csak byte esetben mukodik es word esetben
> befuccsol?

Huhh, tenyleg nem probaltam ki, termeszetesnek vettem, hogy jonak 
kell lennie. Most kiprobaltam, es NEM JO!!!

Hat ez nagyon meglepett. Ezek szerint a paritasbit ugy mukodik, hogy
az eredmeny (ami test-nel meg cmp-nel nem irodik vissza, de a proci
belsejeben megvan) legalso byte-ja paritasat nezi csak!

Meglepo. (Nekem legalabbis :) Sorry!!

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 23 Oct 98 at 16:30,  > wrote:

> GCC ben lehetseges az assembler bete?
> hogyan?

Valahogy igy:

__asm__ ( "pushl %%esi; pushl %%edi; pushl %%ecx;"
          "movl src, %%esi;"
          "movl dest, %%edi;"
          "movl count, %%ecx;"
          "cld; rep; movsl;"
          "popl %%ecx; popl %%edi; popl %%esi");

Szoval AT&T szintakszissal kell irni az utasitasokat (hosszat bele 
kell kodolni az utasitas nevebe, meg % a regiszter neve ele (a 
masodik % a gcc miatt kell csak), $ a konstans neve ele, az 
utasitasok parameterei 'forditott' sorrendben allnak).

Azert push-oltam mindent, hogy az optimalizalastol regiszterekben
tarolt valtozokat nehogy elrontsam. Lehet mashogy is csinalni,
megmondani a forditonak, hogy mik romlottak el. Azt is meg lehet
mondani, hogy tegye bele a valtozokat eleve valamelyik regiszterbe,
illetve a vegen hol lesz az eredmeny. Ez azert jobb a kezi
bepakolasnal, mert az optimalizalast igy ugyesebben tudja csinalni a
gcc:

__asm__ __volatile__ (
  "cld; rep; movsl;"
  : /* nincs output */
  : "S" (src), "D" (dest), "c" (count)
  : "%ecx", "%esi", "%edi" /* ezek romlottak */);

S=esi, D=edi, c=ecx, mogotte zarojelben van a valtozo neve, hogy mit 
toltson bele input-nak. Volatile-t azert irtam oda, hogy nehogy 
valamit ki-optimalizaljon az utasitasok kozul, mert a gcc egyebkent 
meg az asm reszben is hajlando optimalizalni.

Aztan lehet olyat is csinalni, hogy ha nem feltetlenul fontos, hogy
egy adott regiszterben legyen egy valtozo, mondhatjuk azt, hogy
valamilyen regiszterbe tegye bele. Ennek "r" (barmelyik regiszter)
vagy "q" (esi edi kivetelevel barmi) a jele. Az utasitasban a
regiszterre %0 stb. szamokkal hivatkozhatunk (egy % kell csak). pl.
5-tel szorzas:

__asm__ ("leal (%1,%1,4), %0"
         : "=r" (szorzat) /* output barmely regiszter, %0 */
         : "r" (szorzando) /* input barmely regiszterben, %1 */);

(Hu, nem is tudom hirtelen, 4-et kell irni 4-gyel szorzashoz, vagy 
2-ot.)

Nem akarom tovabb reszletezni (lehetne meg...), olvasd el ezeket:

BRENNAN'S GUIDE TO INLINE ASSEMBLY
http://www.rt66.com/~brennan/djgpp/djgpp_asm.html

DJGPP QuickAsm Programming Guide
 irta, mar nem is tudom, hol van a web-en, de 
biztos ra lehet talalni egy keresovel.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Anyi fajta assembly forditot emlegettek a listan.(tasm,masm,wdasm,nasm, etc...)
tud-e valaki egy rovid osszevetest adni mi miert-jo.

En MASM 6.11-et hasznaltam dos,win3.11 - nel es most sikerult megszereznem a 
MASM32-ot ami jo win95,98,nt- re.

			Udv Jan Chika

Sziasztok Coderek!

Meg tudna valaki mondani, hogy hogyan lehet helytakarekosan fontokat
kinyomtatni (pl. csak a nevet irom ki a sajat betutipusaval, egy oldalra ket
hasab)? Ha valaki tud API fuggvenyt, ami kikeresgeti a fontokat, vagy ha van
erre kesz program, legyszives irjatok. Akarmilyen megoldas jo lesz! Elore is
kosz.

Csaba

Sziasztok...

> E-mail :  [United States]

>Erdekes volt Sandor beszamoloja a multkori Coder-ben. Ha a forrasnak hinni
>lehet, akkor nem a rutinokkal, hanem az Intel procikkal lehet gond.

Szerintem nem.

>>Jelenseg: a programot gyors gepen futtatva (>PII 300MHz) indulaskor
>>  Runtime error 200 at ????:91 hibauzenetet ad (Nullaval valo osztas).
                                                  ^^^^^^^^^^^^^^^^^^^^
Ebben en nem vagyok annyira biztos.

Idezet az Intel "Instruction Set Reference"-ebol:
( http://developer.intel.com/design/pentiumii/manuals/24319101.pdf )
"DIV - Unsigned Divide
[...]
Interrupt 0 if the quotient is too large to fit in the designated register
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(AL, AX, or EAX), or if the divisor is 0;"

Szerintem az elobbi verzio miatt van a gond. (Tulsagosan lecsokken DX:AX a 
szubrutinban a gyorsabb procikon.) En tuzolto jelleggel az mondanam,
55 helyett valamilyen nagyobb szammal kellene osztani, hogy az eredmeny
beleferjen AX-be. (Ez elvileg egeszen addig megteheto, amig DX:AX-ben nincs 
nagyobb szam, mint 0xffff*0xffff.) Ekkor csak(?) a delay lesz egy kicsit
gyorsabb, mint kellene, de ez talan nem okoz fatalis hibat.

A fenti megoldas(?) tisztara elmeleti jellegu, se TP-m, se PII-m, ezert nem 
tudom kiprobalni, pedig kivancsi lennek az eredmenyre.

>Ha a forrasnak hinni lehet, akkor a DIV elotti MOV meg nem tolti be CX-be az
>55 erteket mikor a proci mar osztana is (nyilvan a parhuzamos vegrehajtas
>kavar be) es eme szerencsetlen esetben a MOV elott CX erteke telleg nulla.
>Vagy egyszeruen nem CX-szel oszt.

Ajajaj. Ez valami hihetetlenul durva feltetelezes lenne... 
A "bekavaro parhuzamos vegrehajtas"-rol meg... Miert hajtana vegre 
parhuzamosan ket fuggosegben levo utasitast egy szuperskalar proci? Pont 
az a lenyeg bennuk, hogy ugyelnek a fuggosegekre. 

Az az eset, amire Te gondolsz, majd az IA-64-ben (Merced stb.) jo elo, 
amikor a programozo/forditoprogram feladata lesz majd a fuggosegkezeles.
Emiatt kisse maceras lesz oket asm-ben programozgatni...

Balala