Hi!

A LFB lenyege, hogy 32 bites, es linearisan cimezi a memoriat. A BP 7.0
vedett mod csak 16 bites. Ezert nem tudsz eleg nagy tombot deklaralni.
Ez a verzio tehat kifujt.
Az assembler sem tamogatja a 32 bites regisztereket, de ezt ki lehet
kuszobolni manualisan, es igy lehet irni a framebufferbe. Van egy ilyen
forrasom, habar meg sose probaltam ki, ha kell szoljal.
Szerintem BP 7.0 -ban ilyennel nem erdemes probalkozni, mert egy csomo
masik problema is felmerul a 64K-s korlat miatt Javaslom inkabb a Free
Pascalt-t, ami ingyenes, 32-bites, BP 7 kompatibilis pascal fordito.
Letoltheto a http://tfdec1.fys.kuleuven.ac.be/~michael/fpc/fpc.htm
cimrol.
Ha van kerdesed LFB es Free Pascallal kapcsolatban, szoljal.

Gubi

Hali Emberek!
Nem tud valaki valami forumot, ahol egy KEZDO olyan Delphi 3 peldakat
talalhat (forrassal termeszetesen), ami alapjan elindulhat a Delphi
programozasban. A konyvet megvettem (jo draga volt), de jo lenne meg sok
segitseg hozza. Az Animare-t ne ajanljatok, mert felhivtam oket es
meregdragan akartak eladni a mult evi evkonyvet. En megertem, hogy minden
uzlet, meg draga a tudas, de azert a majd' 10 ezer forintot kisse borsosnak
talaltam. (Azert 3 konyvet is meg lehetne venni). Szoval valami olyan
kellene, ami MAGYAR nyelvu, ertheto, es nem tul draga. Ha van ilyen a Gurun
kivul, kernem az elerhetoseget. (Ha lehet a maganba is)
Koszi: Attila

Sziasztok,

Lenne egy apro kerdesem: NT alatt hasznalok BCB-t (3.0) az egyik
munkatarsam meg Dephi-t. (5.0)
Eccer azzal jott, hogy a komponens paletta osszezavarodott (valamikor a
telepites utan), pl a button helyen a button van, de a kep nem stimmel.
Ez igy van majdnem az osszes komponenssel.
Aztan ket nap mulva nekem is ez lett a bajom, persze addig nem igen
hasznaltam BCB-t, lehet azert nem
jelent meg nekem is azonnal.
Kicsit bosszantoooo!!!   :(((
Van meg valakinek hasonlo baja ??
Tudja valaki miert van ez, es mivel lehet megszuntetni ???

Koszi

--
Alex.

Sziasztok!

Windows alatt a programok elszallasakor kinyerheto az
elszallaskori allapotra, kornyezetre vonatkozo informacio.
Ez, ha a sajat programom valamely moduljara "mutat",
akkor tudom ertelmezni. A gondom az, hogy egy nehezen
reprodukalhato (pontosabban eddig nem is sikerult reprodukalni),
elszallas van egy programomban, ami a USER.EXE
Windows modulra mutat. Mivel (tudomasom szerint) ilyenkor
a verem nem is a sajatom, nem tudok semmit sem kezdeni
a kinyerheto infoval.
Tudna valaki valamilyen modot arra, hogy kozelebb keruljek a
hiba behatarolasahoz ezen informacio alapjan?

udv.:
Joco

Sziasztok!

Most installaltam visual c 6.0 professional editiont windows nt 4.0 ala.
volt elotte 5-os c es 5-os java developer is. namost installalas kozben volt
egy olyan hiba, hogy nem tudta registralni az mscal.ocx-et, amirol persze
nem tudom, hogy mi.
a problemam viszont az, hogy nincs help, azt irja ki, hogy the MSDN
collection does not exist, please reinstall developer studio.

1) szerintetek az install hibaja ennek az oka, vagy mas?
2) Mi lehet az oka, mi lehet a megoldas?
3) Hozza tudok-e ferni alternativ modon a helphez?

valaszt maganba kerek, elore is kosz.

math

Tiszteletem!

Egy iskolai feladathoz szuksegem lenne egy rovid kis C programra.
Annyi kellene, hogy kezel valami kis nyilvantartast. Benne egy struct,
amit listara fuz, torol, kilistaz. (fajlkezelessel)
Ha valakinek van egy ilyen, annak nagyon megkoszonnem, ha elkuldene
nekem. Elore is kosz.

The Breeder

>Hogyan tudom elerni az LFB-t BP7.0 alatt prot. modban?
>
>A ModeInfo megadja az LFB cimet, de hogyan tudok oda egy tombot
>deklaralni, es oda irni?
BP7-ben (vagy barmilyen mas 16-bites forditoban) keszult vedett modban futo
programbol sajnos nem lehet igazan kihasznalni az LFB-t, mert egyszeruen nem
vagy kepes 64k-nal nagyobb szelektort letrehozni - tobb kisebbel meg
legfeljebb a lapozashoz szukseges port-muveletek vagy VESA-hivasokat
sporolod meg. Bar egyes VESA BIOS-ok annyira lassuak, hogy lehet, hogy
erdemes lenne foglalkozni a dologgal... Na akkor lassuk!
A dologhoz eloszor is a fizikai cimet linearis cimme kell konvertalni. Mivel
ehhez a BP nem nyujt sajat rutint, igy kenytelenek vagyunk magunk
letrehozni:

function DPMIPhysicalToLinear(PhysAddr: longint; Size: longint): longint;
assembler;
asm
  mov  ax, 0800h
  mov  cx, PhysAddr.word[0]
  mov  bx, PhysAddr.word[2]
  mov  di, Size.word[0]
  mov  si, Size.word[2]
  int  31h
  jnc  @Done
  xor  bx, bx
  xor  cx, cx
@Done:
  mov  dx, bx
  mov  ax, cx
end;

Ha meg van a linearis cim akkor mar eleg konnyu egy ide mutato szelektort
letrehozni:

var LinearSel: word;
      LinearBase: longint;
const MemSize = 65535; { szegmens merete }

  LinearSel:=AllocSelector(0);
  LinearBase:=DPMIPhysicalToLinear(<LFBPhysAddr>,MemSize);
  SetSelectorBase(LinearSel,LinearBase);
  SetSelectorLimit(LinearSel,MemSize);

Ha ugye pl. egy 2 MB-os LFB-t le akarsz fedni akkor a fenti dolgot egy
ciklusban kell ismetelgetned, amiben persze noveled a szelektor-kepzeshez
hasznalt fizikai cimet az elozoleg foglalt szegmens meretevel (64kb) - igy
ugye pontosan egymas utani fizikai memoriateruletekre fognak lekepezodni a
blokkok.

A rohej az egeszben az, hogy ugyanez (ti. LFB elereset egyben) valos modban
siman megy - csak egy aprocska assembly rutin kell hozza amiben 32-bites
index-regiszterrel (pl. EBX) cimzed meg a memoriat... (Maga az asm rutin
akar a Pascal forraskodban is lehet, mert a db 66h prefixet szerencsere at
lehet verni a forditon...)

A legjobb megoldas az lenne ha atternel Free Pascal-ra
(http://www.freepascal.org), mert alatt pl. ez sem gond, leven hogy az az
eleve 32-bites fordito. Szerintem erdemes lenne kiprobalnod...

Gabor

>Tudja valaki, hogy lehet azt megoldani, hogy egy program csak
>valahanyszor legyen indithato ( nehany DEMO program is ezt csinalja ).
>Azaz a szokasos egyszeru datum atirasos ( ha datumot figyel a program )
>modszer ill. a teljes letorles es ujra felmasolas ne legyen alkalmazhato a
>program tovabbi hasznalatara.
>
>Tehat az eddigi inditasok szamat valami rejtett helyen tarolni kellene.
>[...]
>Vajon, hogyan oldjak ezt meg mas programokban ?
A megoldas eleg trivialis: az ellenorzeshez hasznalt adatokat valamilyen
olyan tarolo egysegen es/vagy teruleten kell elhelyezni amit lehetoleg a
legnehezebben lehet torolni. A baj csak az, hogy minel biztonsagosabb egy
egyseg ebbol a szempontbol annal kevesbe valoszinu, hogy
- konnyu elerni es programozni
- minden gepben megtalalhato es minden konfiguracioval (egyutt)mukodik
- olcso, mert ha a draga vedelem magat a kesztermeket is dragitja, amivel
igy nem biztos hogy nyerunk (hiszen igaz, hogy kevesebben lesznek kepesek
majd illegalisan masolni, de kevesebben is veszik majd meg az eredeti
szoftvert is a magas ara miatt, es nem biztos, hogy igy az egyenleg
elonyosen valtozik)
Raadasul ha tenyleg jo es/vagy nepszeru a szoftver ugyis rovid idon belul
megjelenik hozza a tores. Eppen ezert szerintem manapsag nem erdemes tul
nagy  feneket kerekiteni a dolognak - egy viszonylag egyszeru modszer is
megteszi, amit eleg ha az atlagfelhasznalo nem tud atverni/"feltorni".
(Azert nem erdemes bonyolult vedelmet kidolgozni, mert barmilyen rafinaltak
is vagyunk szinte biztos, hogy valaki fel tudja majd torni (ugye mindig van
okosabb nalunk) es igy leginkabb csak magunknak okoztunk kart azzal, hogy a
vedelem fejlesztesere forditottunk jelentos eroforrasokat.)
Tehat pl. Windows alatt nyugodtan hasznalhatjuk a registryt valamilyen
specialis kulcsertek eltarolasara - csak arrol gondoskodjunk, hogy egyreszt
a kulcs jelentese ne legyen feltetlenul nyilvanvalo (pl. ProgramInstallDate
kulcsnev nem igazan rulla ;), masreszt, hogy az adattartalombol vagy eppen a
kulcs helyebol se lehessen feltetlenul kovetkeztetni funkciojara.
Ugyanilyen jo (meg DOS alatt is mukodo) megoldas lehet ha egy specialis
fajlt helyezunk el valahol a merevlemezen, de lehetoleg eleg messze a
program-konyvtartol, valami ritkan torolt helyen, pl. a Windows\System
konyvtaraban. A fajl tartalmat szinten kodolni erdemes - na nem RSA-val,
csak pl. ne legyen kozvetlenul olvashato ASCII szoveg, es ugye a fajl neve
se utaljon funkciojara.
Persze, a fenti megoldasok mindegyikenek hatranya, hogy a rendszer
torlesekor ezek az adatok is elvesznek es igy vegul is az illeto
ujratelepiheti a programot, vagy hogy megfelelo monitorprogramokkal (pl.
regmon, filemon) megnezheti, hogy milyen ertekeket/fajlokat irkal/ellenoriz
a programunk es maga is elvegezheti ezek torleset. Ezzel azonban a mar fent
emlitett okok miatt nem erdemes kulonosebben foglalkozni: tokeletes
(kijatszhatatlan, feltorhetetlen) vedelmet ugy sem tudunk letrehozni -
leginkabb csak majd azt sikerul elernunk, hogy a johiszemu felhasznalo gepen
sem fog elso futtataskor sem elindulni a programunk valami inkompatibilitasi
problema miatt.
A masik, hogy mivel a rendszer minden komponense cserere kerulhet "normal
uzem" soran is, ezert barhova is taroljuk a szoban forgo informaciokat azok
barmikor "eltunhetnek" a rendszerbol. Ezzel a problemaval ugy sem fogsz
tudni mit kezdeni (- ha csak nem mellekelsz a programohoz egy
rendszer-fuggetlen tartozekot. ez ugye a hardverkulcs)...

Na, mar megint tul sokat jart a szam... ;)

Gabor

Sziasztok!
Eddig az MSVC-t hasznaltam, de most Borland termekre kell atternem.
Tudja valaki, milyen elonye, hatranya van a C++-nak, C++ Buildernek es a Delphi
nek egymassal szemben? (pl.: kodgeneralas, futtatas sebessege, ...)
Koszi: 
Attila