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