Hollosi Information eXchange /HIX/
HIX CODER 1217
Copyright (C) HIX
2001-06-25
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Linux utility keresztforditas (mind)  16 sor     (cikkei)
2 Re: Delphi gyorsasag (mind)  42 sor     (cikkei)
3 Re: io.sys, msdos.sys (mind)  12 sor     (cikkei)
4 Re: Windows Hook (mind)  9 sor     (cikkei)
5 Re: Re: Windows Hook (mind)  33 sor     (cikkei)

+ - Linux utility keresztforditas (mind) VÁLASZ  Feladó: (cikkei)

Nem tudja valaki veletlenul, hogy hogy kell Linux utility-ket egy
masik rendszerre leforditani ?

A fejlesztorendszer Intel linuxon fut, a target egy ARM alapu kis
linuxos szerkezet. A kernel gyonyoruen konfiguralhato ARM-ra, lefordul
az Intel gepen es letoltes utan fut is ahogy kell.

Ezzel szemben a tobbi program (jelen esetben a mount) configure -ja
nem fogad el semmifele --target=arm-linux meg --prefix --with-headers
meg hasonlo opciokat es mindenaron az Intel gepre akarja leforditani
a programokat.

Nincs nagy kedvem a GNU makefileokat kibogozni, ezert ha valaki tud
valami egyszeru megoldast, azt megkoszonnem.

Zoltan
+ - Re: Delphi gyorsasag (mind) VÁLASZ  Feladó: (cikkei)

> Delphiben irok egy fuggvenyt:
> function Mindegy(hogy: string): string;
> begin
> //itt valami komolyabb string-transformaciokat csinalunk
> end;
>
> Egyesek azt mondtak, hogy gyorsabb, ha allandokent adom at az illeto
> valtozot, es a fuggvenyben deklaralok egy valtozot, ami felveszi ennek
> az erteket, es aztan azzal manipulalok.
Ez nem gyorsit semmit, sot, csak lassabb lesz. A konstans parameterek
hasznalata csak abban az esetben gyorsit, ha az atadott struktura sem
kozvetve sem kozvetlenul nem kerul modositasra, mert ilyenkor tok felesleges
annak tartalmat a stack-re meg lemasolni, hiszen az eredeti peldany
adataival lehet dolgozni annak megvaltoztatasanak "veszelye" nelkul (hiszen
ha const-nak deklaralt parametereket nem engedi a fordito modositani).
Ha te egy parametert const-kent adsz at, majd sajat magad masolod le egy
lokalis valtozoba, azzal ugye semmit nem sporolsz meg (a fordito ugyanezt
csinalna helyetted, ha nem const lenne a parameter), csak esetleg az
optimalisnal lassabb masolast sikerul megvalositanod.

> Meg egy kerdes: rovid, egy-ket soros dolgokat erdemes fuggvenykent
> deklaralni? pl.
Ezt mindig az donti el, hogy atlathatobb forraskodot, vagy pedig gyorsan
futo programot szeretnel. Altalaban minel kevesebb szubrutint hasznalsz,
annal atlathatatlanabb lesz a kod, es annal tobb problemad akad amikor majd
karban kell tartni (hiszen 1 helyett majd 100 helyen kell modositani rajta).
Persze a lo masik oldalara is at lehet esni (amikor minden apro dolgot kulon
szubrutinba rak az ember, tok feleslegesen), de nem ez a jellemzo.
Amugy a fuggvenyhivasok alapvetoen nem esznek tul sok CPU ciklust
(legalabbis Variant tipusu valtozok hasznalatahoz, vagy egy-egy API fuggveny
hivasahoz kepest), igy nem nagyon tudsz ezekkel sporolni. Persze nagy
iteracioszamban mar eszreveheto a kulonbseg, de csak nagyon primitiv
muveletek (kb. osszeadas-kivonas kategoriara kell gondolni) tudom
elkepzelni, hogy a hivasok a teljes futtatott kod emlitesre erdemes reszet
tegyek ki.

A fuggvenyhivasoknak persze meg van az a hatranya is, hogy kulon blokkolra
bontjak a kodot, amiket igy fordito mar csak kulon-kulon tud majd
optimaliazalni, es ami adott esetben jelentosen rosszabb eredmenyhez vezet,
mint ha egyetlen blokkon belul szerepelne az osszes muvelet.

Gabor
+ - Re: io.sys, msdos.sys (mind) VÁLASZ  Feladó: (cikkei)

> Ha emlekeim nem csalnak, akkor a ket rendszerallomanynak (IO.SYS es
> MSDOS.SYS sorrendben) kell a ket legelso gyokerkonyvtarbeli
> konyvtarbejegyzesnek lennie. (Felteve persze, hogy MSDOS-t hasznalsz, es
nem
> IBMDOS-t vagy Novell DOS-t)
Ez csak a 3.3-as DOS-ig volt igy. Az 5.0+ verziokban a boot loader
automatikusan atscanneli a gyokerkonyvtart, es barhonnan kepes betolteni
oket (tehat barhol lehetnek a lemezen, de persze a gyokerkonyvtarban kell
bejegyezve lenniuk). (A 4.0-s DOS-rol nem tudok pontosat, de ezt Europaban
nem is bocsajtottak ki.)

Gabor
+ - Re: Windows Hook (mind) VÁLASZ  Feladó: (cikkei)

Hello!

Ha a KeyboardProc-ba MessageBeep-et teszek, akkor tenyleg
pittyeg rendesen, de magamtol a C++Bulder-hez
adott Win32 SDK Reference cimu helpben
semmit nem talaltam arrol, miert nem megy
a PostMessage HookProc-bol.

Peter
+ - Re: Re: Windows Hook (mind) VÁLASZ  Feladó: (cikkei)

Szevasz Peter, Szevasztok!

>Felado :  [Hungary]
>De sajnos az en programom meg mindig csak az installalo
>threadben torteno dolgokat kapja meg, es nem erdekli,
>melyik konyvtarba rakom.

Igy elso ranezesre azt javaslom - ha meg nem tetted meg, - hogy valaszd szet
a hook fuggvenyedben az uzenet elkapast es az uzenet atadast, addig, amig a
hook nem megy. Ugyanis a dll-bol a hook fuggvenyedben az uzenetadas a
foprogramnak megint nem megy olyan siman. A hook fuggvenyed magjaban csak
egy MessageBeep-et tegyel. Amig ez nem mukodik, addig raersz atadni az
uzenetet.

Tehar a hook fuggvenyed a kovetkezo legyen:

LRESULT CALLBACK RKOPKeyboardProc( int code, WPARAM wParam, LPARAM lParam )
{
 if ( code == HC_ACTION )
//     PostMessage( DestinationhWnd, MYWM_KEYRECEIVED, wParam, lParam );
     MessageBeep(1);

return( CallNextHookEx( KeyboardHook, code, wParam, lParam ) );
}

>Amit kaptam program, most mar mukodik, hogy betettem PATH-ba.

Ez remek, de a masik fontos, amit irtam, hogy statikusan linkelt legyen a
dll-ed. Ez megvan?

(::-{)> Torma Istva'n, TOR, 
(Kuldtem listara es maganba is.)
A valaszokat ide a listara kerem, mert olvasom es mert mast is erdekelhet

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