Hollosi Information eXchange /HIX/
HIX CODER 442
Copyright (C) HIX
1999-04-27
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Euler-kor (mind)  11 sor     (cikkei)
2 Re: bitszamolas (mind)  56 sor     (cikkei)
3 Re: String C++ (mind)  74 sor     (cikkei)
4 JPG es GIF deCoder (mind)  14 sor     (cikkei)
5 .avi lejatszas memoriabol (mind)  9 sor     (cikkei)
6 Re: C - 286 (mind)  11 sor     (cikkei)
7 Re: file handles (mind)  42 sor     (cikkei)
8 dll hívás (mind)  23 sor     (cikkei)
9 Re: libc5, libc6, Linux driver (#441) (mind)  25 sor     (cikkei)
10 Rendezes Delphi tablaban (mind)  16 sor     (cikkei)
11 Resource WorkShop (mind)  10 sor     (cikkei)
12 Re: bitszamolas... -->Mc (mind)  82 sor     (cikkei)
13 Re: jump if ... (mind)  14 sor     (cikkei)
14 [Mar megint] Ikonok .EXE-bol (mind)  11 sor     (cikkei)
15 Par napja volt, szamok betukkel (mind)  23 sor     (cikkei)
16 JPG forras VC ala. (mind)  12 sor     (cikkei)
17 Re: bitszamolas + miegymas... -->Mc (mind)  29 sor     (cikkei)
18 Re: conditional jump /short, near, dword;) (mind)  28 sor     (cikkei)

+ - Euler-kor (mind) VÁLASZ  Feladó: (cikkei)

Hollo !

Az lenne a kerdesem, hogy ismer-e valaki olyan algoritmust, ami egy
iranyitott grafban keres Euler-kort ? (Tehat nem csak eldonti, hogy
van-e, hanem meg is hatarozza.) Akar program (barmely nyelven),
akar pszeudokod nagyon jo lenne !
(Maganban is megkoszonnem, mert surgos !)

Elore is kosz,

ferceg koma
+ - Re: bitszamolas (mind) VÁLASZ  Feladó: (cikkei)

On 25 Apr 99 at 0:59,  > wrote:

> hi
> 
> kicsit lemaradtam. magamtol en is csak rekurzioval oldottam volna meg,

No, vegre valaki :))

> de ahogy elneztem a tegnapi valaszokat, tenyleg a ketszeres ciklus
> a leggyorsabb.
> 
> azert itt van egy-ket meres (pII orajel-ben, vc6 fordito.
> char[256] tablazatot general, ott lehet jol optimalizalni :)

Tetszenek, foleg a harmadik (optimalizalt rekurzio): Ha ebbol
kihagyjuk a 4-szeres ciklus rolling-out-ot (hogy lehet ezt magyarul
mondani, kibodoritas?), akkor kiderul, hogy ez valojaban egy teljesen
uj algoritmus, nem a korabbi rekurzio optimalasa. Ha jol ertem, 
(sokaig tartott, mig megertettem :), azon alapul, hogy egy bit 
hozzaadasaval 1-gyel nol az egyesek szama. A while ciklus adja hozza 
felvaltva a 80,40,20, stb. biteket, aztan a rekurzio kitolti a 
kozottuk fennmarado lyukakat. Remelem, jol ertem :) Nehez 
megfogalmazni, de lehet, hogy Te jobban tudnad...

Egyebkent az ilyen rekurzio kuriozumnak jo, de valojaban nem ezeket 
szeretem. A rekurzio akkor jo, ha egyszerubben atlathato (es 
bizonyithato) lesz tole a program helyessege.

Erdekesek a meresi eredmenyek is, jo, hogy megmerted.

No, kaptam ma egy ujabb megoldast is, Kovacs Emoketol (aki mellesleg 
a szomszed asztalnal ul mellettem). Ez is egy teljesen uj algoritmus, 
es erdekessege, hogy _nem_ ketszeres, hanem egyszeres ciklus!
Raadasul nem ugy egyszeres, ahogy Csiszar Laszlo ciklusa (mert az 
valojaban az if-ben a kulso ciklust rejtette el), hanem maga az 
algoritmus nem igenyli a dupla ciklust!

Alapotlete kicsit hasonlo, mint a Te optimalizalt rekurziode, bar
attol teljesen fuggetlenul keletkezett: Ha tudjuk egy X szam
egyeseinek a szamat (E), akkor 2*X-nek szinten E, 2*X+1-nek pedig
E+1 darab egyese lesz.

Ennyi az otlet, a program pedig mar konnyen adodik:

for (tomb[0]=0, i=0; i<128; i++) {
  tomb[2*i] = tomb[i];
  tomb[2*i+1] = tomb[i]+1;
}

Ennyi az egesz.

Most eppen ez a megoldas tetszik nekem a legjobban :)

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - Re: String C++ (mind) VÁLASZ  Feladó: (cikkei)

Kedves Istvan!
> Tulleptem ma a sorlimitet, ugyhogy elkuldom kozvetlenul.

:-( Sorlimit sux... :-)

> > > > Remelem nem irtam nagy marhasagot...
> > >
> > > Csak egy picit :))
> > > Az abc ugyanis nem pointer.
> > 
> > Szerintem meg igen.
> 
> Pedig bizony nem... :))

Dedededede! Es a dupla stipi-stopit nem er megkontrazni! :-)

> De az a gyanum, hogy nem az ellen bizonygatjatok ezt, ami ellen en 
> irom. Az termeszetesen igaz, hogy amikor a tomb nevet onmagaban 
> hasznalod, az az expression a tomb elso elemere valo mutatora fog 
> kiertekelodni.

Nem. Nem arra ertekelodik ki, hanem az az erteke, mint pointer.

> Ugyanugy, mint egy szubrutin neve is, annak a 
> kifejezesnek is a szubrutin kezdocime lesz az erteke.

Nem. A fuggveny is egy pointer. Nem ugy ertekelodik ki, mint egy pointer, 
hanem az valoban egy pointer, ami egy fuggvenyre mutat.

> Ettol azert meg nem
> mondja senki, hogy a szubrutin az egy pointer. :)

Ha egyszer az, akkor minek lehetne meg nevezni???

> > leforditott ertek lesz a def-ben es utanna nem irhatod at. Ugyanis
> > forditaskor 29 byte le lesz foglalval valahol es az erre mutato POINTER
> > betoltodik a def pointer-be.
> 
> Nincs def pointer sehol a memoriaban, ahova betoltodhetne barmi is!

Dehogynem. Nezd meg a kodot asm-ben.

> > Igyexem alatamasztani az allitasomat
> [...]
> > Ha az abc nem a "valahol elhelyezkedo tomb"-re mutato pointer lenne,
> > hanem maga a tomb, akkor valami zagyvasagot kellene kiirnia. De nem azt
> > irja ki. Tehat abc egy pointer.
> 
> Szoval a szohasznalatban van kulonbseg koztunk: Te ugy hasznalod a 
> tomb nevet, mint a kifejezes erteket (ami egy pointer), en meg 
> szemantikailag (ami egy tomb, ami kifejezesekben az elso elemere 
> mutato pointerkent ertekelodik ki).

Attol meg a tomb neve az egy pointer. A tomb maga persze, hogy az a terulet, 
amit a memoriaban lefoglal a compiler. Erre viszont erre a tombre mutato 
pointerrel lehet hivatkozni. Azaz abc-vel.

> > Az a kulonlegessege, hogy const. Bizonygatas:
> ...
> > char abc[]="ABC";
> > char *p=abc;
> > abc=p;
> ...
> > >cc x.c
> > "x.c", line 4: left operand must be modifiable lvalue: op "="
> 
> Ez a hibajelzes nem azt jelenti, hogy konstans!! Hanem azt, hogy nem
> lvalue.

Es egy valtozo mikor nem lvalue? Amikor konstans! Vagy neeeem?

Udv From: a pointer

Idot, penzt, faradsagot takarit meg, ha idot, penzt, faradsagot takarit meg...
+ - JPG es GIF deCoder (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok CODER-ek   !

Kerdesem a kovetkezo :
  Egy kalandjatek programot szeretnek irni . Mar minden majdnem
tokeletesen mukodik csak egy gondom van . Espedig : ugy gondoltam , hogy
mindenik oldalra kulon rajzot teszek.
Ez mind szep es jo csakhogy egy 640*480-as 256 szinu bmp 308kb -ot foglal.
Ezt megszorozva 350-el(ennyi oldalas lesz a jatek) "szep kis" szamot kapunk.
 Ezert arra gondoltam , hogy Jpg vagy Gif-eket olvasok be, mert azok
aranylag keveset foglalnak.
Tehat nagyon halas lennek ha valaki vagy mondana egy jo megoldast , vagy
kuldene egy jpg , gif  beolvasot .

               Laci
+ - .avi lejatszas memoriabol (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok,

Nem tudja valaki, hogyan lehet egy .avi fájlt a memóriából lejátszani?
Tehát előszőr a memóriába be kellene olvasni a fájlt, aztán onann
lejátszani.

Köszi minden segitséget.
Levente

+ - Re: C - 286 (mind) VÁLASZ  Feladó: (cikkei)

>halas koszonetem annak a varazslonak, aki megfelel a kovetkezo kerdesre:
>Hogyan lehet valamely C-t (Turbo, Borland) uzembe helyezni 286-oson ???

A Borland C hasznalja a DPMI-t, a Turbo C nem -- ha jol tudom. Szoval a
regi Trubo C-t tedd fel, persze azzal nem lehetett C++ -olni, vagy probald
ki a BCC-t (command line-os forditoja a Borlandnak, ott kell legyen a bin
konyvtarban), hatha az lefut (persze akkor mas szovagszerkesztot kell
hasznalnod, de a helpet rezidensen is elindithatod a THELP programmal --
szinten BIN konyvtar...).

Tamas
+ - Re: file handles (mind) VÁLASZ  Feladó: (cikkei)

Hmmmm, szoval mas levelre valaszolva irtam meg, ime megismetelve:

> Hat oszinten megmondom, hogy nem vagyok abban biztos, hogy ez a
> legegyszerubb megoldas (lehet, hogy van valami undocumented funkcio, ami
> kapasbol megmondja). Viszont ez is mukodik (Borland C++ 3.1-el probaltam).
>
> #include <stdio.h>
> #include <dos.h>
>
> struct SFTstru {
>   struct SFTstru far *Next;
>   unsigned num;
>   /* a tobbi nem lenyeges most */
> }; /* FSstru */
>
> int main (int argc, unsigned char *argv[])
> {
>   struct SFTstru far *SFT; /* Pointer to File System Table */
>   union REGS regs;
>   struct SREGS sregs;
>
>   unsigned sum = 0; /* ebben szamoljuk ossze az egyszerre megnyithato
> file-ok szamat */
>
>
>   regs.h.ah = 0x52; /* List invar */
>   intdosx(®s, ®s, &sregs);
>
>   /* +4, hogy rogton a SFT-re mutato pointerre mutasson */
>   SFT = MK_FP(sregs.es,regs.x.bx+4);
>   SFT = SFT->Next; /* Most kapja meg az elso System File Table cimet */
>
>   while (FP_OFF(SFT) != 0xFFFF)
>   {
>     sum += SFT->num; /* ebben az SFT-ben levo file-ok szama */
>     SFT = SFT->Next; /* kovetkezo SFT */
>   } /* while */
>
>   printf("FILES=%u\n",sum);
>
>   return 0;
> } /* main */
+ - dll hívás (mind) VÁLASZ  Feladó: (cikkei)

Hello Coderek!

Egy aprócska problémám van, amin közületek valaki talán tud segíteni.

Adott egy C-ben írt dll fájl ami - többek között - tartalmaz egy függvényt, ami
t VB 5.0-ből meg szeretnék hívni. A függvényt nevezzük például WSProperties-nek
 .
Paraméterként egy struktúrát és két integer-t kell megadni.

Úgy tűnik minden szabályszerűen van kódolva (a VB-ben), de valami miatt mégsem 
tetszik neki.
A hibaüzenetek: Run-time error '49'. Bad dll calling conversion.
Így a meghívás mégsem jó.

A szívesség, amit kérnék:
Kérlek benneteket írjátok meg, hogyan hívnátok meg egy ilyen függvényt (VB kódo
t kérnék).
Ha valaki komolyan segítene, szívesen elküldöm neki a fájlokat is (kis fájlokró
l van szó), s a metódust, ahogy megpróbáltam meghívni.

Szívességeteket előre is köszönöm.

Üdvözlettel:	Mező Dezső )
+ - Re: libc5, libc6, Linux driver (#441) (mind) VÁLASZ  Feladó: (cikkei)

On Sun, 25 April 1999,  wrote:

> Meg tudja nekem mondani valaki (tomoren), hogy mi a kulonbseg a libc5
> es libc6 kozott?

Pontosan ugyan nem neztem, de ez biztos egy jo kiindulopont:
http://www.gnu.org/software/libc/libc.html

> Mas: lehet olyat csinalni, hogy az Xes programom kozvetlenul nyulkal egy
> porthoz, 

nem

> vagy kell hozza irni egy drivert, modulba pakolni, es a drivertol kerni,
> amit akarok? (tv tuner)

igen (de nem kell feltetlenul modulba pakolni, bar az jobb)

Hogy egy driver hogyan tudja elerni az IO-mapped memoriat, azt Linus a 
/usr/src/linux/Documenation/IO-mapping.txt - ben irja le.

Avagy:
http://lxr.linux.no/source/Documentation/IO-mapping.txt

Barna
+ - Rendezes Delphi tablaban (mind) VÁLASZ  Feladó: (cikkei)

Szisztok!

A kedes az alabbi volt:
Csak 1 kerdes: mi van, ha van 1 tablam es azt vmelyik (a user menet kozben
valtoztathatja) oszlopa szerint szeretnem megjeleniteni.
Lehet, hogy amator, de en ugy csinaltam, hogy a szoba joheto oszlopkra
csinaltam index-et. Amikor a user a DBGrid fejlecere kattintott, akkor azt
beallitottam aktualis index-nek. Igy akar novekvo csokkenot is konnyu
csinalni, es nem kell SQL. Persze biztosan lehet szebben is...

Udv

Szucs Zoltan

ui.: Valaki kerdezte, es engem is erdekel, hogy egy EXE-bol hogyan szedhetem
ki az ikonjat. Nem Resource WorkShop-pal, hanem programbol!
+ - Resource WorkShop (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok!

Csak egy rovid kerdes: Hasznal valaki Win NT alatt 32 bites Resource
WorkShop-ot? Mar minden file-t beszereztem hozza megse megy. Egy kis
homokorazas aztan semmi? Masnal '95 alatt persze megy.
Megoldas? (Nem cserelem le az NT-t!!!  :-)))  )

Udv

Szucs Zoltan
+ - Re: bitszamolas... -->Mc (mind) VÁLASZ  Feladó: (cikkei)

Hi inet,"HIX CODER" >!

elozetesbe annyit, hogy en vagyok az a so:ro:s mc36 ;)/
csak eppen szerintem ez a level mar nem menne fel a so:ro:s cimrol
a 99 sor limit mijatt... /telleg, igen tisztelt moderator bacsik,
nincs kedvetek eszt emelni egy kicsit? ;))))))))))))))))))))))))))
vagy csak rijogatas vegett van benne a doxxban? ;)))))))))))))

no en magam reszerol valahogy ugy csinalnam, hogy...
 - kiuritem a tablazatot...
 - osszeszamolnam, hogy mejik bytebol mennyi van...
 - majd vegigmennek a tablan, es szorozni ezerrel...
ui: kar, hogy nem lehet shr-t hasznalni, mert azzal egy kicsit
    gyorsra lehetne aszt a BitCountot irni... de jo, legyen neked,
    most akkor keresgeld meg a bsf es a btr c-s +felelojet.. ehehe;)))
    /lehetett volna bsr el is, csak az meg ennel is _LASSABB_..;))))
> -----------------------------------------------------------------------
call clearTable        ;tabla torlese...
sub si,si              ;a psp kezdete...
mov cx,100h            ;es hossza...
call processBuffer     ;na szamojjunk 1et...
call GetResult         ;es az eredmeny is jol jonne...;)))
ret

proc clearTable
mov di,offset DataTable      ;a tablazat cime...
mov cx,256                   ;hany elembol is all?
sub eax,eax                  ;0aval toltyuk fel....
rep                          ;mondom feltoltyuk!!!;)))
stosd
ret                          ;errol ennyit...
endp

proc processBuffer
;in: ds:si-buffer ofs
;    cx-bytes in buf
jcxz processBuffer_j1        ;ha nincs mit tenni, akkor nincs mit tenni;)))
mov edi,offset DataTable     ;a tablazat cime...
sub eax,eax                  ;ez kell, hogy az al folotti resze 0 legyen...
processBuffer_j2:
lodsb                        ;na nezzuk az elso bytet...
inc dword cs:[edi+eax*4]     ;trukk... a tablazatba novejjuk a szamlalot...
loop processBuffer_j2        ;es az ossszes byte-n vegig megyunk...
processBuffer_j1:
ret                          ;na mos'ma' lassan csovaz van...
endp

proc GetResult
;out: ebx-seted bits found
sub eax,eax                  ;ugyancsak a felso resznek 0 kell hogy legyen;)
sub ebx,ebx                  ;ez pedig a szamlalonk... neha nem art 0azni;)
mov edi,offset DataTable     ;ez a tablazat cime...
GetResult_j1:
call BitCount                ;na nezzunk hany 1es is van ebben a byteban?
imul ecx,cs:[edi+eax*4]      ;* hogy hany ijen bytet talaltam....
add ebx,ecx                  ;vegul novejjuk a szamlalonkat....
inc ax                       ;majd mennyunk a kovetkezo karakterre...
cmp ax,100h                  ;meg mindig nincs vege?!??!?
jb byte GetResult_j1         ;na akkor fojtassuk eszt a jatekot...
ret                          ;es vegre itt a vege...
endp

proc BitCount
;in: ax-char, out: ecx-bits seted...
push dx                      ;mert is ne mencsunk? ;))))
push ax
sub ecx,ecx                  ;a szamlalo torlese...
BitCount_j1:
bsf dx,ax                    ;keressunk 1 bitet...
jz byte BitCount_j2          ;aki keres, nem mindig talal-->vegre vege! ;)))
inc cx                       ;ollejj, novejjuk a szamlalot...
btr ax,dx                    ;torojjuk a talalt bitet...
jmp byte BitCount_j1         ;es ujra, 6ha van meg kis lapulo bitecske...
BitCount_j2:
pop ax                       ;de ha mar mentettunk, akko' szeggyuk is vissza!
pop dx
ret                          ;na ennek is vege van...
endp

DataTable dd 256 dup (?)     ;mejik bytebol mennyit talaltunk...;)))
> -----------------------------------------------------------------------
na jo kodolast...   Mc  /ezeccer a pentagonbol..;)))))))))))))))))))))
+ - Re: jump if ... (mind) VÁLASZ  Feladó: (cikkei)

szia,
asszem 386-on vannak iklyen utcsik...
a mnemonik ugyanaz,de az opkod elso byte-ja 0f

nezz utana...
szia.
peon

On Sat, 24 Apr 1999  wrote:

> Az assembly felteteles ugrasavial kapcsolatban lenne egy kerdesem. Meg
> lehet-e azt oldani, hogy
> egy ilyen ugrassal 128 bajtnal tavolabbi cimekre is lehessen kozvetlenul
> ugorni?
+ - [Mar megint] Ikonok .EXE-bol (mind) VÁLASZ  Feladó: (cikkei)

Szi!

Van egy masik megoldas is: a Delphi 3-ban van egy olyan demo, aminek az a
neve, hogy Resource Explorer. Az tud ilyeneket. Sot: mindenfele dolgot
kiszed: bitmapeket, animokat, stb.

Udv:

Gaby
______________________________________________________________________
http://www.sch.bme.hu/~gyoreg  mailto:  ICQ#:19934854
+ - Par napja volt, szamok betukkel (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok.

Kb. egy hete volt rola szo, es utananeztem, hogy hogy is hivjak azokat a
nagy szamokat, amiket Mc kerdezett.
na szoval:

  A := Conv_Tagolas(Conv_HaromSzam(I,'trilliard'),O)+A;       { 10^21 }
  I := Int(I/1000);
  A := Conv_Tagolas(Conv_HaromSzam(I,'quadrillio'),O)+A;      { 10^24 }
  I := Int(I/1000);
  A := Conv_Tagolas(Conv_HaromSzam(I,'quadrilliard'),O)+A;  {?{ 10^27 }
  I := Int(I/1000);
  A := Conv_Tagolas(Conv_HaromSzam(I,'quinquillio'),O)+A;     { 10^30 }
  I := Int(I/1000);
  A := Conv_Tagolas(Conv_HaromSzam(I,'quinquilliard'),O)+A; {?{ 10^33 }
  {---> kerdes: aki tuggya fojtatni az nyugottan szojjon..;) <---}

(viszont aki innen tudja folytatni, az megintcsak szoljon :)
Amugy nem sok ertelme van idaig eljutni, mert meg a comp tipus is csak
trillios (vagy trilliardos) nagysagrendig tud abrazolni.

Sziasztok,
	HTGe
+ - JPG forras VC ala. (mind) VÁLASZ  Feladó: (cikkei)

Hali Coder!

Tudna nekem segiteni valaki subjectbeli temaban?
Van egy forrasom,de mivel lama vagyok VC bol
ezert nem tudom,hogy a pelda alkalmazas miert
csak 16 szinnel rakja ki a kepet -tudom tipikus
tudatlan  kerdes ,de eddig a Delphi t nyuztam.
A forras VC 4.1,egy kis emlekezteto szintaxis 
BYTE * RGBbuffer = ReadJPEGFile(filename,&width,&height);
SaveJPG(RGBbuf, width, height...);
Elore is koszi minden segideget!
			Csaba.
+ - Re: bitszamolas + miegymas... -->Mc (mind) VÁLASZ  Feladó: (cikkei)

Hi inet,"HIX CODER" >!

iC> A test allitja a carry-t (nincs keznel leiras)? Akkor nem kellene az
iC> ugras, csak adc al.
a test allittya a carry-t... 0azza...;)))))))
szerinted egy test /azaz and/ utaSITas utan hol lesz neked
olyan szitud, hogy az eredmeny nem fog beleferni a regbe? ;)))

iC> Szerintem fontosabb a jol olvashato kod mint a gyorsasag, kiveve, ha
iC> a gyorsasag kritikus.
nemtom, szerintem a jol olvas6o kod a VisualXXX nyelvek jellemzoje...;)))

-------------------------[mas... hehe, eger rulez;]-------------------------

iC>     mov si,offset bitterkep
iC>     mov cx,length(bitterkep)*8-1
iC>     xor dx,dx
iC> cycle:
iC>     bt  [si],cx
iC>     adc dx,0
iC>     dec cx
iC>     jns cycle
ize, ez szep es yo, felteve, ha a bitterkep hossza maximum 2 byte...
gondojj bele monnyuk egy 64 byte hosszu bitterkepbe...;)))) akkor
a cx-ben mar 64*8-1 lesz... az ugye 511... de akkor jon az alap kerdes,
hogy egy wordben /bt [si],cx ugye wordos utaSITas/.... te6 egy wordben
hogy lehet letesztelni az 511. bitet? ;))))))))))))))))))))))))))))))

na jo kodolast... Mc
+ - Re: conditional jump /short, near, dword;) (mind) VÁLASZ  Feladó: (cikkei)

Hi inet,"HIX CODER" >!

iC> Az assembly felteteles ugrasavial kapcsolatban lenne egy kerdesem. Meg
iC> lehet-e azt oldani, hogy egy ilyen ugrassal 128 bajtnal tavolabbi cimekre
iC> is lehessen kozvetlenul ugorni? Elore is koszi a valaszokat!
sza'l eloszor is pontoSITok... -128..+127... de amugy a valaszom
az, hogy termeszetesen van conditional jump short, near, soot
dwordos valtozatban is... a near es a dwordos valtozat ugyan
386+, de azert azok is vannak.... ime egy kisebb pelda, a tasm
frankon generalja is a nearos valtozatot ebben az esetben:
> ------------------------------------------------------------------
 .586p
code segment para use16
assume cs:code,ds:code
org 100h
start:
mov ah,0eh
mov al,'a'
int 10h
stc
jc j1          ;ebben az esetben egy near jc fog fordulni...
data db 1024 dup ('abcd')
j1:
ret            ;ha lehet /T vel linkeld...  exe suxx 4eva...;)))))
code ends
end start
> ------------------------------------------------------------------
na jo kodolast, oszt legyetek jok...     Mc

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS