Hollosi Information eXchange /HIX/
HIX CODER 668
Copyright (C) HIX
1999-12-11
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Re: SOS DELPHI (mind)  38 sor     (cikkei)
2 Re: proci tortenelem (mind)  46 sor     (cikkei)
3 RE: sz@r nyelv & goto (mind)  37 sor     (cikkei)
4 lock (mind)  38 sor     (cikkei)
5 Re: proci tortenelem (mind)  31 sor     (cikkei)

+ - Re: SOS DELPHI (mind) VÁLASZ  Feladó: (cikkei)

>Hogy tudom megcsinalni, hogy irok Delphiben egy programot es nem akarom,
>hogy megjelenjen alol a toolbarban, vagyis hogy ne lehessen kilepni
>belole normalis modon!!!!! Legfentem az Ora, meg a billentyuzet mellett
>a jobb also sarokban, de ha lehet akkor csak a TASK MANAGERREL lassam.
>Nem tudnavalaki nekem erre gyorsan egy megoldast kuldeni!!!!
Az ablak eltuntetese a taskbarrol: ShowWindow(Application.Handle,SW_HIDE);
Azonban tray icon keszitesere gyors (3 soros) modszer nincs igazan... (Amugy
a Shell_NotifyIcon() kornyeken probalkozzal!)

>MEg ha lehet meg valami. Szeretnek Delphi programbol elinditani egy
>szalat egy iciri piciri prioritassal, ezert, hogy a progi ne foglalja le
>nagyon a rendszert. Hogy tudom ezt megcsinalni, milyen metodusokat kell
>felulirni es hogy. A szal azt kellene csinalja, hogy teszteli  az eltelt
>idot es ha lejart ujra bootol a gep, vagy ha lehet kiir valamit es
>utanna lefagyasztja a gepet.
>Meg lehet ezeket csinalni???
Uj szal inditasahoz egyszeruen letre kell hozni egy peldanyt egy TThread-bol
leszarmaztatott objektumbol. Persze a leszarmaztatott objektumban felul kell
irni (override) a thread Execute metodusat, ugyanis ez az ami a futas (az
szal "elete" soran) vegrehajtodik... Amikor ez befejezodik akkor a
thread-nek is vege - ez azt jelenti, hogy ennek a metodusnak teljesen
blokkolo jellegu (tehat nem mint egy esemeny-kezelo, ahol veges idon belul
_feltetlenul_ vissza kell adni a vezerlest, hogy ne alljon meg a teljes
alkalmazas).
A thread prioritasa annak Priority property-jenek (ki gondolta volna?;)
segitsegevel allithato.
Bovebb informaciot es peldakat a help-ben talalhatsz a dologrol...
Bar a gep lefagyasztasra valoszinuleg tobb modszer is letezik (pl. Windows
inditasa, betoltes utan eger mozgatasa, stb. ;), en ezzel nem igazan
probalkoznek, mert egyreszt nem igazan praktikus (pl. adatvesztes es tarsai
miatt) masreszt nem latom mi a teteje a dolognak...
A Windows-bol valo kilepesre pedig az ExitWindows() ill. ExitWindowsEx()
fuggvenyek hasznalhatok...
De megmondom az oszintet: nem ertem, hogy egy watchdognak (mert ugye ezt
akarsz csinalni, nem?), miert kellene kilepnie a Windows-bol, ha megall egy
progi???

Gabor
+ - Re: proci tortenelem (mind) VÁLASZ  Feladó: (cikkei)

>> Csak egy megjegyzes: Ha jol emlexem, akkor a 80286-os nem volt teljesen
>> komptabilis a 8086-ossal. Ha minden igaz, akkor a stack-re
>> pakolgatasnal a masolas es a SP valtoztatasa mas sorrendben tortent...
>
>Ez azert durva lett volna, nem ott volt a kulonbseg. Volt valami
>hasonlo tenyleg, ha jol remlik, akkor egy exception-nel (talan div0)
>volt kulonbseg, hogy a push-olt IP az utasitasra, vagy az utasitas
>moge mutat-e.
Miert lenne durva a dolog? Szerintem nem ez lenne a legdurvabb
inkompatibilitasi problema az Intel torteneteben...
Az egeszben egyebkent az a szep, hogy tenyleg igaz az SP-s dolog - mar
megint csak az i386 doksijat tudom idezni:


"14.7  Differences From 8086
[...]
  4.  Value written by PUSH SP.

      The 80386 pushes a different value on the stack for PUSH SP than the
      8086/8088. The 80386 pushes the value of SP before SP is incremented
      as part of the push operation; the 8086/8088 pushes the value of SP
      after it is incremented. If the value pushed is important, replace
      PUSH SP instructions with the following three instructions:

      PUSH  BP
      MOV   BP, SP
      XCHG  BP, [BP]

      This code functions as the 8086/8088 PUSH SP instruction on the
80386."

Szoval - errol ennyit...

Azt hiszem fel fogom rakni valahova a webre es akkor szepen majd mindenki
elolvasgathatja mielott allandoan belekot a masikba - amikor az igazat
mond...

Amugy egyebkent a pluszban emlitett dolog is igaz:

"  2.  Divide Exceptions Point to the DIV instruction.

      Divide exceptions on the 80386 always leave the saved CS:IP value
      pointing to the instruction that failed. On the 8086/8088, the CS:IP
      value points to the next instruction."

Gabor
+ - RE: sz@r nyelv & goto (mind) VÁLASZ  Feladó: (cikkei)

>>> Kulturaltabb nyelevekben meg ott van a strukturalt exception handling 
>>Lattad mar, hogy milyen ASM kod van mogotte? Valoszinuleg a programozo 
>>szamara kenyelmes megoldas, es biztosan attekinthetobb a forras... 
>Viszont a hibakezeleseket egy helyen el lehet intezni, nem kell minden hivas 
>utan a return code-ot elemezgetni, kiugrani, stb... 
>A mai gepeken az alkalmazasok 99%-anal ez nem okozhat gondot. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ezt mar nem birom....  pont az ilyen hozzaallas alazza verig azokat a
programozokat, akik hatekony progikat akarnak irni (sajnos ok vannak
kissebbsegben). A mai mentalitas az, hogy 5 perc alatt osszedobunk
valamit egy vizualis nyelven, ami annyit tud, hogy kirak egy ablakot meg egy
gombot. Az egesz 3 mega, es egy erogep kell neki....
Persze minek ilyen aprosagokkal torodni, hiszen a mai gepek legalabb
PII-esek, es minimum 128M ram van bennuk....
Ennek az egesznek a hardware gyartok orulnek a legjobban, mert a
szerencsetlen felhasznalonak meg kell vennie az erosebb gepet, hiaba
akar o csak teszem azt szoveget szerkeszteni...
Mi (akik programozonak nevezzuk magunkat) mi tehetunk arrol, hogy
mikozben a gepek teljesitmenye a csillagos egig no, addig a programok
hatekonysaga allando, sot azt is meg merem kockaztatni, hogy egyes
alkalmazasok teruleten csokken. Pedig csak egy kis odafigyeles es plusz
raforditott ido kellene. Tudom, hogy az utobbi a problemas, de errol is "mi"
tehetunk; ha a megrendelo latja, hogy 2 nap alatt is meg lehet csinalni azt,
ami kulonben 3 het lenne, nana hogy a 2 napot valasztja....
Bocs, ha hosszu voltam, de ezt ki kellett adnom magambol.

Visszaterve az eredeti temahoz,
a goto arra jo, hogy megkeverje a vizualis "fogd es vidd" modszerhez
szokottakat a feltetlen vezerlesatadas egyszerusegevel..... ;))))
A processzor nem hulye, nem tudja, hogy mi az a "strukturalt exception
handling", o csak annyit tud, hogy IGEN/NEM (nagyon sarkitva), ha ezt
szem elott tartanatok (akinek nem inge nem veszi magara), akkor nem
torne ki ilyen ostoba flame.....

--
JimBoo >
Suse 6.0 v2.2.7
+ - lock (mind) VÁLASZ  Feladó: (cikkei)

sziasztok,

tud vki megoldast a kovetkezo problemara?

kliensek olvasnak/irnak egy megosztott objektumot. az utkozesek
elkeruleset lockolassal akarjuk megoldani, azaz, ha egy kliens
modositani akarja az objektumot, bejegyzi magat a szerveren, h most ove
az objektum, utana beolvassa az erteket, szuttyog rajta egy kicsit,
kitalalja az uj erteket, beirja, aztan torli a lockot a serveren. amig
az objektum lockolva van, masik kliens nem ferhet hozza.

namost. igen kellemetlen kovetkezmenyekkel jarhat, ha egy kliens, miutan
lockolta az objektumot, meghal/lefagy/vegtelen ciklusba
kerul/mittudomen, mindenesetre keptelenne valik a lock megszuntetesere.
ezt elvileg meg lehet oldani ugy, hogy a kliens, amig lockol, bizonyos
idokozonkent jelzi a szervernek, h meg el. csak ket problema van:

1. ha az objektumfeldolgozo ciklusban helyezzuk el a visszajelzo
utasitast, idonkent elofordulhat, h tul sokaig dolgozgat, es igy nem tud
idoben visszajelezni, a szerver pedig ezt ugy ertelmezi, h a kliens
meghalt.

2. ha kulon threadben tortenik az idonkenti visszajelzes, lehet, h a
kliensalkalmazas ugy hal le, h a visszajelzo thread beragad, es tovabb
kuldozgeti az eletjeleket. ez tenyleg elofordul, nalunk is tortent mar
ilyen.

szoval, vannak-e jobb modszerek a lock befagyasanak elkerulesere?
esetleg tudna-e vmelyikotok ajanlani olyan weboldalt v konyvet v barmit,
ami a lockolas kerdesenek ilyes megkozelitesevel foglalkozik? vagy
esetleg barmilyen otlet, h milyen kulcsszavakra erdemes keresni a weben,
h ilyen megoldasokat talaljak?

az esetleges otleteket legyetek kedvesek maganmailben is, mert eleg
surgos volna.
koszi, elore is.

weisz balint ]
+ - Re: proci tortenelem (mind) VÁLASZ  Feladó: (cikkei)

On 10 Dec 99 at 17:55, Sting > wrote:

> > > Ha minden igaz, akkor a stack-re pakolgatasnal a masolas es a
> > > SP valtoztatasa mas sorrendben tortent...
> >
> > Ez azert durva lett volna, nem ott volt a kulonbseg. Volt valami
 ...
> Miert lenne durva a dolog? Szerintem nem ez lenne a legdurvabb
> inkompatibilitasi problema az Intel torteneteben...
 ...
>   4.  Value written by PUSH SP.
 ...
> Szoval - errol ennyit...

Eloszor is bocs, a push sp-t tenyleg elfelejtettem.

Viszont az, hogy *altalanosan* a stack-re pakolgatasnal maskor
valtoztatna az SP-t, az ha jobban belegondolsz, *nagyon* durva lenne.
Egyetlen korabbi stack frame-es szubrutin (push bp + mov bp,sp) se
mukodne...

> Azt hiszem fel fogom rakni valahova a webre es akkor szepen majd
> mindenki elolvasgathatja mielott allandoan belekot a masikba -
> amikor az igazat mond...

Hmmm, azert azt nem gondolom, hogy "allandoan" oktalanul kotok bele
a masikba.

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

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