• #106171 PROHARDVER!

  Új Válasz 2025-08-29 16:38:34 #106171

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  PROHARDVER!

  (rögzített hozzászólás)

  Legyetek szívesek az offtopik témákat ne ebben a topikban tárgyaljátok ki. A topikgazda is jelezte, most törölni kellett jópár hozzászólást, most már maradjatok a (szakmai) topik keretei között.

Új hozzászólás Aktív témák

• #82569 Sokimm senior tag BoB #82568

  Új Válasz 2022-01-29 13:35:50 #82569

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sokimm

  senior tag

  válasz BoB #82568 üzenetére

  U ilyet még nem is láttam, thx a linket!
  Gondolkodtam vajon mi a létjogosultsága a kiterjesztésnek ezek után.
  (nem kell megnyitni, majd bezárni a file-t, hogy egy keresőt (magas szintű nyelv) lefuttassunk esetleges kiterjesztés keresésre? (*.mp3)? )
  Mondjuk a kiterjesztést nem tudom miként tárolja a rendszer, mert maga a file-t (bináris adathalmaz) a keretrendszer (adott esetben OS (win vs linux)) határozza meg, hogy amikor az adott adat "elejét végét" beolvassa, milyen infókat ad a user felé, tehát a kiterjesztés a bináris kód elején végén lehetne, mint a link tartalma is. Így ha a keresőt assembly szinten az mp3 bináris megfelelőjére engednénk rá, kiterjesztés helyett is lehetne a file-ban szereplő "zene" azonosítót keresni.
  De akkor a címek tárolására az összes bináris "start bit" lehetne a pointer memória címe? (az után meg mindaddig olvassa a rendszer, míg nem látja a vég signal-t?
  Ekkor mondjuk nem tudnánk a méretet, csak ha végig megyünk a kezdő címtől a végéig (lehet most is így megy a méret számolás?). De akkor mi lenne, ha a tárolóból törlünk középről egy zenét, majd beteszünk egy nagyobb zenét a helyére, és a "vége", ami nem fér be a régi zene helyére, az új címre kerülne, amivel már az első szekció (nagy zene vége) kell egy címet is tárolni, amivel a második szekcióra mutathatunk, és így folytonos lehet az adatolvasás. (defrag?)
  Extra: Ha most kellene feltalálnom a spanyol viasz 2.0-át, akkor a kezdő file signature után egyből betenném az adott típusú (file) tároló méretét (például: D partició:4TB, nyuszika.rar esetén 400MB, kiskutya.JPG: 3MB, readme.txt: 4kB és így tovább és így tovább)
  Ekkor az alacsony szintű nyelvünk pointere ha megtalálja a kívánt adatot, egyből kiolvasná a méretet is (tudná milyen mennyiségben kell read-elni, ezzel tudna erőforrás foglaláshoz energiagazdálkodni (szálasítás, időzítés), anélkül, hogy végig kelljen menni a tárolt adat egész bináris során csupán azért, hogy méretet határozhasson meg.

Új hozzászólás Aktív témák