>Szeretnek nem negyszog alaku ablakokat letrehozni, de
>sajna nem jutottam sokra. Ha itt mar sikerult valakinek,
>az legyen szives irja meg, hogyan.
Egy regiot (HRGN) kell letrehoznod a kulonbozo region-fuggvenyekkel (pl.
CreatePolygonRgn(), CreateEllipticRgn(), CombineRgn(), stb), majd a
SetWindowRgn()-nal ezt kell beallitanod az ablak vagasi regiojanak...

Gabor

Hali!

> Ha valos modban vagyok, es a realflat be van allitva, akkor meg lehet
> azt csinalni, hogy 1 mega folotti cimrol inditok DMA atvitelt memoria es
> hangkartya kozott?
>
>  Tamas Selmeci / TOR][UM 

Ugy emlexem,  nekem ment... Ha akarod utananezek a regi
progijaimban!

-- 
Üdv: Gilbert atya ~~~~ (Gilby/MKSZTSZ) ~~~~ 

Hello!

megtalaltam a leirast, de egy olyan input mezo kellene, ami minden
billenyuleutesre megkapja a beirt stringet, hogy folyamatosan ki tudja
irni, hogy mi passzol hozza. ilyet hogy tudok csinalni?

Bye,
Szabolcs

> Az erdekelne, hogyan lehet NT alatt a numlock lenyomast
> szimulalni.Vagy, honnan vesz az NT, hogy a belepes utan
> a numlock be van-e kapcsolva vagy nincs.

A NUM_LOCK billentyu belepeskori statusza felhasznalonkent
valtozhat. Alapertelmezettkent ki van kapcsolva. Ezt beal-
litani a kovetkezo kulcscsal lehet:

HKEY_USERS\.Default\Control Panel\Keyboard\InitialKeyboardIndicators,

Erteke 0 tol 2-ig valtozhat.

Forras: MSDN Library Knowledge Base, Article ID: Q154529

Toth Gabor (Laurel Kft)

Hali!
Nem vagyok meg otthon Delphiben ezert lehet hogy nagyon lama a kerdesem.
Szuksegem lenne Delphi 3(32bit) alatt valodi elojel nelkuli 32 bites
egeszre. Van e ilyen mert a Cardinal az egy atvagas, a LongInt-el meg
nagyon munkas ugykodni az elojelbit miatt, a Comp meg a tobbiek szinten
nem vagy nagyon nehezen hasznalhatoak. Van e erre megoldas (esetleg
valahogy sajat valtozotipust deklaralni)?
Gallo Laszlo

On  3 Nov 99 at 11:56,  > wrote:

> Igy mar a "00":"01":"10"-nak 42:36:22 a szazalekaranya.
> A "0"-nak  42+(36/2)+(22/2) = 71%
> Az "1"-nek    (36/2)+(22/2) = 29%

Annak, hogy az egyes biteknek mi az aranya, szerintem semmi 
jelentosege. Ha ugyanis a 00, 01, 10 bitparosak helyett pl. 11110, 
11101, 01111 bit-otosoket hasznalnal (csak a hasamra utottam), attol 
meg semmi sem valtozna, az uzenet informaciotartalma ugyanannyi.

> >> 75-85%-ra tomoritette.
> > En rosszabra szamitottam. Mennyinek orulnel?
> Ha CSAK 1 blokkot tomoritek akkor 1.5-33% az arany.
> Ha TOBBET akkor ugrik fel 75-85%-ra. Itt van vhol elasva a
> kuty.

A szamokat nem ertem, hogy hogyan hasznalod, ekkora lesz tomorites 
utan a file, vagy enyivel csokken a merete? No, mindegy, szamoljuk ki 
az elvi korlatokat:

Ha nem hasznalod ki tomoriteskor az uzenet 'betuinek' sorrendisegeben
levo fuggosegeket, hanem csak a 'betuk' gyakorisagat, akkor elvileg 
az optimalis tomorites a kovetkezo tud lenni:

betu valosz -log2
---- ------ ------
'00', 0.42, 1.2515
'01', 0.36, 1.4739
'10', 0.22, 2.1844

Fentebb a valoszinusegek 2-es alapu logaritmusa (negalva persze)
adja a 'betu' kodolasahoz elvileg szukseges bitek szamat. Az entropia 
(vagyis szumma valosz*bitek)=1.5368, ez azt jelenti, hogy atlagosan 
ennyi bit kell egy 'betu' kodolasahoz, tehat egy 1000 'betus' 
uzenethez, aminek eredetileg 2000 bit a hossza, elegendo 1537 bit.
E szerint a kompreszio nyeresegenek elvi hatara kb. 23%

A multkori 1:3:3:1 gyakorisaghoz 1.8113 entropia tartozik, ott tehat 
kevesebbet lehet nyerni a tomoritesen, csak 9%-ot. Feltetelezem, hogy 
az '11' bitsorozat eliminalasa soran kicsit nagyobb lett a file 
merete, attol lehet most jobban tomoriteni. Vagy persze az is lehet 
jo esetben, hogy nem a gyakorisagokon, hanem valami mas redundancian 
valtoztattal most, es ettol tenyleg az entropiaja csokkent a 
file-odnak.

Szoval elvileg az aritmetikai kodolas ehhez a 23%-hoz kozelit, ettol 
tobbet ne varj tole.

> > En ennek nem orulnek ennyire.
> En mar 1%-nak is orulok :)))

A Huffman kodolas 1*0.42+2*0.36+2*0.22=1.58-cal kozeliti az igazi
entropiat, vagyis 21%-ot tomorit. Ettol az aritmetikai 2%-kal jobb, 
ugyhogy akkor hajra :)

Viszont ha nem betu-statisztikan alapulo kodolast csinalsz, akkor 
elkepzelheto, hogy az aritmetikainal is jobb eredmenyt kapsz, de 
ahhoz mar nem lehet tomoritest becsulni.

> Ha megvizsgalom a szazalekokat, akkor a tizedesjegyek hossza
> mennyiben befolyasolja az aritmetikai kodolo minoseget???

Minel inkabb igazak a hasznalt valoszinusegek az uzenetben 
eloforduloakhoz, annal inkabb kozeliti az aritmetikai kodolas a 
Shannon altal bizonyitott elvi korlatot.

> Azert erdekel mert az aritmetikai tomoritest 16/32 bites
> kodban is meg lehet irni. Ekkor imho mar szamit a tizedesjegyek
> hossza.

32 bit nagyon kicsi egy rendes aritmetikai kodhoz, keszulj fel tobb 
100 (vagy meg inkabb 1000) bites aritmetikara.

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

Hali !

>>Meg 1 tipp : kozvetlen hardwerhozzaferessel kezelni a drive-t, mely a
>Azt nem tudom a kerdezo mire gondolt, viszont ugy gondolom a CRC hibas
>szektorok, a "ha a speci floppyrol bootolok hozzaferheto, egyebkent nem"
tipusu
>megoldasok nem biztonsagosak.

Haat, asszem lassan eljutunk a "doku titkositas" tema utjara.
Szerintem sem biztonsagosak - ezt is leirtam mar - de gondold magad
a kerdezo helyebe /aki idaig sem jelentkezett.../ : meg mindig nem
kapott valaszt a kerdeseire. Pontosabban most mar igen :

>Ezert kell kriptografiai filerendszert alkalmazni, vagy az egesz diszket
>elkodolni (megintcsak kriptografiailag bizonyitott modszerekkel), es
drivert
>irni az adott oprendszerre hozza.

Egyebkent koszi a cimet!
				Jo szorakozast !
					Gusi

Hali !

>> Elobb megkene talalni a vegeredmeny elojelet, utana elvegezni
>> az egyebkent jo otletet vegeredmeny-elojelfuggoen
>> megvalasztott konstansokkal !
>Nem tudom, mindenfelekeppen muszaj ennyire ragaszkodni a totalis
>platformfuggetlenseghez? Egy kis asm makro sokkal hatekonyabban es
>atlathatobban megoldja a problemat, es mas procira atvinni se egy
>nagy kunszt.

Szerintem is, de nem ez volt a kerdes, s en csak pontositottam...bocsi...

ui.: nincs otlet a "Clipper tomb kezelese asm-ben" c. kerdesre ? ;-((

				Jo szorakozast !
					Gusi

Szia!

Antifagyi írása elég reménytelen vállalkozás.
Viszont eddig két jó fagyidetektáló módszerrel találkoztam:

Az egyik hardware-s:  kell egy egyszerű készüléket csinálni, ami
printer porton át fogad jelet, ha az bizonyos intervallomoknként
megérkezik OK, ha nem csinál valami (szirénázik, stb.) Abban a
programba amibe be szándékoznak építeni a figyelést el kell, helyezni
a printer-port írást.
Elsőre lehet bonyolultan hangzik, de a "Vezérlések párhuzamos poron
keresztül" c. könyv alapján+némi elektronikai ismerettel könyen
megcsinálható...

A másik, egyszerűbb szoftware-s: annak a programnak a fö-ciklusába
amit figyelni akarnánk, be kell építeni egy eljárást, ami bizonyos
időnként létrehoz egy háló-drive-on egy file-t, és egy figyelő gépen
ellenőrizni kell, hogy nem túl régi-e a file...

ZsZs.

In article >,
   wrote:

[...]
>Szoval egy fogaskerdes (legalabb is szamomra).
>Lehet-e antifagy progit irni??
>Szoval az lenne az igazi, ha egy kifagyo gepnel
>felismerne a fagyas tenyet, es ha lehet, akkor
>el is haritana.
[...]

Szia!

Hogy egy software lepeseket tegyen hogy elharitsa a
fagyast, ahhoz elore tudni kellene mikor fog a gep
fagyni.  Ezt mar a 1930 evek vegen kidolgozott Turing
univerzalis teoria ( Turing Theorem; Universal Version )
bebizonyitotta hogy ilyen es ehhez hasonlo problemak
megoldhatatlanok.

Endre

Szia!

Ezt csak VxD-vel tudod megcsinalni, ugyanis a 
\\PHYSICALDRIVE0 path csak az NT-s Win32 API
eseten muxik. A Win95-ben ez nincs benne.
Amikor meg a VirusBusternel dolgoztam, akkor
ott is igy kellett megoldani. Pontosan mar nem
emlexem, hogy hogyan ment, szerencsere nem nekem
kellett vele foglalkozni, en csak hivogattam,
de eleg gany volt.

Valami olyasmi remlik, hogy inicializalaskor a
kernelben vegigszaladt a drive leiro strukturakon
es megkereste a megfelelo drive-hoz tartozot.

Kesobb meg a pointerre hivatkozva hivott valami
speci fuggvenyt.

Oke, nem vagyok tul konkret, de hatha segitettem
valamit.

Csao!

Balazs